Fix plan creation / registration bug

[mattjohnsonpint]

There were some issues with retrieving the correct execution plan that came down to how functions were registered.

Previously, the plugin loader would create a plugin and then register all of the functions in it. Each function would separately be registered and an execution plan created and associated with it at that time. The registration is done by function name.

The problem was that if a plugin was reloaded, and the names hadn't changed but the metadata changed in a way that would modify the execution plan (ie., SDK language, signatures, type ids, etc.) then the old plan was still in the registry and was being used with the new plugin - resulting in a runtime error when the function was called.

The fix was to have the execution plans created at the same time the plugin object is associated, then update all the related places where we register functions or retrieve them. That way, a plugin's functions, it's metadata, and its execution plan can never become disassociated. This also affords some optimizations. In particular, when a host function is invoked, we no longer have to ask the registry for the execution plan. Instead we can get it directly from the active plugin.

There were a few other minor bugs that surfaced while fixing this, which are also fixed in this PR.

[linear]

HYP-2223 Function re-registration can lead to incompatible metadata / plan

One symptom is switching SDKs.

Try the HTTP example from the Go SDK. Then, without restarting the Runtime, try the HTTP example from the AssemblyScript SDK. You'll get an error:

ERR Panic in host function. error="interface conversion: langsupport.WasmAdapter is *assemblyscript.wasmAdapter, not *golang.wasmAdapter"

Restart the Runtime and the query will work fine.

In the opposite direction, a different error occurs:

ERR Error decoding input parameters. error="pointer is not to a string"