Use a per-`documentLoader` resolved context cache.

[davidlehn]

Fixes an issue where multiple document loaders are used which each have different values for static contexts.

A WeakMap is used for caches and is cleaned up using WeakMap semantics based on the lifetime of the documentLoader keys.

[davidlehn]

A bit more info for this issue:

• This depends on a document loader using the (I think undocumented) feature of setting a resolved context result with a tag of "static". That triggers storing in a "shared" cache that is used between calls to the library.
• If multiple API calls are made using multiple document loaders, and each resolves the same URL to a different value, this can cause an error.
• This is probably not a common pattern, but can appear in test suites for example.

About this initial fix:

• Handled at the top level and uses unique shared caches per documentLoader.
• The cache resources used will scale with the number of document loaders used.
• The WeakMap usage should hopefully clean up resources depending on how apps document loader lifetimes.
• Alternative approaches would likely be in ContextResolver and either also keying on a documentLoader, or tracking and checking the loader in the values. This seemed to be pushing the fix a bit far down in the resolver details.

For future work, the entire caching setup should be revisited. Apps should have more control over cache use, size, and duration. There are many ways this could be designed.