Add parser recovery for unfinished interface implementation

[auduchinok]

Adds recovery for unfinished interface ... with that contains no members but is already given with keyword.

Example 1: before (interface impl is not parsed at all, subsequent declarations are corrupted):

Example 1: after (everything is parsed, type check results are available for the next declaration):

The main problem with the example above is when with is present without any members, it simply fails to parse, skips other declarations, and no error about missing members is reported at all (for a user or tooling to fix it).

Example 2: before (subsequent member is considered to be interface part):

Example 2: after (subsequent member belongs to the type declaration):

The current behaviour in the second example may actually be an intended behaviour. I've initially thought that from my experience it usually did more harm than good, since subsequence members do have the correct offset for the type declaration, but now I'm thinking it shouldn't have been changed. This part can easily be reverted by using < in the LexFilter change instead. @dsyme @cartermp What do you think about this change?

[cartermp]

but now I'm thinking it shouldn't have been changed.

Yeah, this one is tricky. I think I would prefer the old behavior because out of the two following scenarios:

1. User already has a member M scoped to the class, then adds the interface declaration above the member P
2. User adds the interface declaration, then adds a new member M to implement that interface but doesn't have their indentation correct (e.g., has smart indentation turned off in VS)

The second one feels more likely to happen. But neither is really "correct".

[auduchinok]

If returning the old behaviour, subsequent members have to be member declarations that are allowed in interface implementations, which limits recovery severely:

I'm thinking about other approaches.

[auduchinok]

OK, subsequent members are parsed properly now and belong to the type, and the indentation warning in this particular case is reported by the parser instead of LexFilter.

The warning range is larger with this approach, but a similar range is used in some other places in the compiler already and is probably not that bad. We don't have the first token range info at this point anymore anyway.

Technically this is a breaking change, since it was possible to implement interfaces without further indenting members, but I much prefer how it's handled now with an explicit error and properly parsing all type members around.

[auduchinok]

@cartermp @vzarytovskii The test failures seem unrelated, have you seen this before?

[vzarytovskii]

@cartermp @vzarytovskii The test failures seem unrelated, have you seen this before?

That is a weird one, looks like some agent hiccup, I'll take a look.

[cartermp]

Thanks, this is approved pending tests passing. I like the adjustment!

[auduchinok]

This is ready.

[TIHan]

Looks good to me, awesome