Fix stale schema registrations

[jdesrosiers]

This PR fixes how workspace schemas identified by $id get registered and unregistered in the SchemaStore

• Stale $id registrations: when a file's $id changes or the file is deleted, its previous $id is now unregistered, even if nothing had compiled the schema yet.
• Dependent schemas: a schema that references a changed file is now re-registered instead of being dropped.
• $id normalization: Fragments are now removed from $ids so they don't break triggering revalidation of dependent documents.

[srivastava-diya]

I was thinking, what about the case where the file that owns the$idis the one that gets deleted? like if a.json and b.json both have "$id": "https://example.com/something" and b.json was registered last, deleting b.json gives Unable to load resource 'https://example.com/something' for any document whose $schema is that $id, even though a.json still declares it. its not something introduced by this PR i believe also not sure if duplicate $ids are just considered a user mistake and not worth handling though.

[jdesrosiers]

Good point. It is a user mistake, but I do think we need to handle it. I think we should push diagnostics to show there's a conflict. We also need to handle recovering from that situation like you describe. It's the user's fault, but we need to recover gracefully if they do make that mistake.

[jdesrosiers]

I worked on this for a while and it got pretty complicated, so I decided to leave it for a separate PR. I'll create an issue.