Loading Extensions must unify on JSon.Net

When Script loads an extension, it needs to unify JSON.net (and potentially other core dlls).

If the user code loads JSON.Net, the runtime's current policy is to not unify that reference with the runtime's copy. That means that the runtime will load v9 and the user code may load v10 (the latest). This is exacerbated that other nugget packages will depend on v10 since by default, it pulls the latest.

This is a good policy if the JSON.Net is truly internal. But a bad policy for any other case - especially a) if the user signature binds to JObject; b) for any extensions (see https://github.com/Azure/MikeBindings/issues/21 ). However, it's a breaking change to change it.

But since extensions are a new feature, we could say extensions unify - and that's not a breaking change.

For extensions, the general principle here should favor unifying dlls, else any types shared between the host and the user code will break. This can happen for types in the user's signature.

Start by tracing how Script loads extensions and how the runtime applies assembly-binding policy to JSON.Net and other core DLLs. Reproduce the v9/v10 mismatch with an extension whose signature uses JObject, then verify that extension loading unifies shared dependencies without changing the general runtime policy.

Written by the indexing model from the issue text.