Fix Kubernetes schema priority after resource-specific schema resolution

[shin19991207]

What does this PR do?

Kubernetes auto-detection replaces the configured all.json URI with a document-specific _definitions.json or CRD URI. However, schema priorities are registered against the original all.json URI. Looking up priority using the document-specific URI caused it to receive the lowest priority, allowing other schema sources such as SchemaStore to incorrectly win.

This PR fixes the issue above and includes several related enhancements to Kubernetes support:

• Treats an omitted Kubernetes API group as the internal core group. For example, apiVersion: v1 is parsed as { group: "core", version: "v1" }, allowing a Pod to match the io.k8s.api.core.v1.Pod definition. Unknown core resources fall back to all.json instead of being searched for in the CRD catalog
• Creates a separate CodeLens entry at the beginning of each document in a multi-document YAML file
• Displays specific CodeLens titles for Kubernetes resources, such as Pod (Kubernetes v1.36.1) and MutatingAdmissionPolicy (Kubernetes v1.36.1), instead of displaying the general all.json / _definitions.json
• Preserves extensionless schema URI names instead of incorrectly appending .json. For example, a schema URI ending in schema is displayed as schema, not schema.json, because schema resources may be JSON, YAML, or extensionless

What issues does this PR fix or reference?

Fixes #1298

Is it tested? How?

• Automated tests

• Tested the case reported in Confusing interaction of schemastore and kubernetes manifests #1298. Verified that:

  1. Both documents are validated against their corresponding Kubernetes schemas, and validation errors are reported for both.
  2. A CodeLens appears at the top of each document and links to the corresponding schema.

• Tested that an unknown core kind falls back to all.json instead of being resolved through the CRD catalog. For example, expected the following YAML reports a diagnostic on Po: Value is not accepted. Valid values: "MutatingAdmissionPolicy", "MutatingAdmissionPolicyBinding", "MutatingWebhookConfiguration"..., rather than attempting CRD validation:

  apiVersion: v1
  kind: Po
  metadata:
    name: irrelevant

[datho7561]

Works really well and addresses the issue. I think the changes to CodeLens especially are super important. Thanks, Morgan!

One thing that might be interesting, to align with the other changes to CodeLens in this PR, is to have it say "Kubernetes v1.36.1" instead of "all.json" when it's validating against Kubernetes but not any specific resource kind. Do you think that's interesting, and if so, do you want to implement that here or in a different PR?

[shin19991207]

@datho7561 Yes that makes sense! I'll implement it in this PR as well.

[artem-nefedov]

The PR title says "Fix ... for multi-document YAML", but the problem I reported is also reproduced with a single-document file (e.g. one containing just MutatingAdmissionPolicy).

[datho7561]

Here's an edge case I ran into:

The code lens ends up on the previous line for the third document that's empty. I don't think this is a big deal, but it might be worth fixing.

[datho7561]

It works really well and it's really helpful. If you think #1309 (comment) is worth addressing now, that might be worth it. Otherwise, I think this PR is good to merge, so feel free to go ahead and do that.

[shin19991207]

@datho7561 Thanks for catching this edge case! I fixed the issue so the CodeLens is now placed on the line after a trailing --- when a following line exists.

[datho7561]

Looks good! Thanks, Morgan!