Fix free range validation for delayed `contains` nodes.

[NTaylorMullen]

• In scenarios where contains nodes would occur post-item nodes our validator would explode because it'd validate item nodes at their time of occurrence. Meaning if you had:

  ...
  { "label":"item" .... "inVs":[123] }
  ...
  { "label":"contains" .... "inVs":[123] }
  ...

  We'd validate the item node and see if there was a contains node that mentioned it's inVs.

• This changeset adds a new postValidate path and changes the existing validate interactions to pass multiple elements (instead of one at a time) so we can ensure that we've iterated over the entire set prior to callign postValidate

  • Ultimately this is how C#'s LSIF generator operates which led me to this validate interaction.

• Added a test for C# specific files that takes in a C# LSIF file and validates that no validation errors have occurred.

[dbaeumer]

I think this validates the last constraint documented here: https://microsoft.github.io/language-server-protocol/specifications/lsif/0.6.0/specification/#emittingConstraints

This constraint got added on special request of the CodeIndex team :-). So we need to check if this can really be loosened.

[NTaylorMullen]

Talked offline: Looks like this is an intended restriction with the intention to ease LSIF consumption of tools like CodeIndex. Meaning, once an item element is parsed you're guaranteed to know what document that item belongs to so you don't need to keep as much in memory.

[NTaylorMullen]

Will close that out with this restriction /cc @jasonmalinowski