add value completion.

[srivastava-diya]

Description

1. Suggests values for a property based on what its schema allows. Completion.ts is now an orchestrator over two providers PropertyCompletion for keys, ValueCompletion for values and MatchingSchemaCollector is split into AnnotationEvaluationPlugin and CompletionEvaluationPlugin.

2. What it suggests

• const / enum → the exact permitted values
• type → a snippet placeholder per type ("", {}, [], true/false, null, number, integer)
• both, when a schema permits specific values and anything beyond them, for Eg.

"anyOf": [
  {"enum": ["uri","ipv4","ipv6"]}, 
  {"type": "string"}
] 

3. Keywords handled
   type enum const not allOf anyOf oneOf if/then/else $ref properties additionalProperties required

4. There are two paths, and they exist for different reasons:

• Evaluation hooks observe the validator running, keyed by instance pointer. This covers combinators at the object level, at any nesting depth, including inside array items.
• resolveValueInfo helper reads a property's own subschema statically, because when we're typing "color": there's no value yet for the validator to go into. That path has to interpret applicator keywords itself, which is why $ref and then/else appear there explicitly.

Out of scope for this PR.

• Filtering keywords (minLength, pattern, minimum, …) will be a follow-up.
• Decorations will be seperate PR

Testing

45 value-completion tests (1 skipped) , all asserting the complete response. Value tests are grouped by keyword with comment markers.

[jdesrosiers]

I pushed a few minor updates for style and performance. But, more importantly, I added a couple tests to expose some edge cases that were missed.

Overall, I'm not comfortable with how complex this got. I feel like there must be simpler way, but it's ok for now.

[srivastava-diya]

I added a couple tests to expose some edge cases that were missed.

Thanks for adding those.

Overall, I'm not comfortable with how complex this got. I feel like there must be simpler way, but it's ok for now.

i know, it looks pretty overwhelming, i am working on simplifying the logic, i'll update you with the progress very soon.

[srivastava-diya]

if is a condition, not a constraint, it tests the data, it doesn't restrict it so without this flag we will walk into the if subschema and record its properties as a real constraint on the same property. That constraint then gets intersected with the property's actual schema, which wrongly narrows the completions, hence this flag is necessary.