`near_vm_runner` has to deal with two distinct UniversalEngines when artifact is already loaded in memory

[nagisa]

In the current runtime whenever we evaluate a function call action, we will create a new instance of the contract runtime engine (e.g. near_vm::UniveralEngine.) Normally this is quite alright -- we then load the executable with this engine to obtain a UniversalArtifact, which represents a loaded but not instantiated wasm module for that runtime.

This process of loading the UniversalArtifact stores some data within UniversalEngine -- things like type descriptors and such.

Now in some instances we may want to store some of these UniversalArtifacts warmed up in memory ready to instantiate quickly. However that poses a problem -- next time around a new call comes in, we create a new UniversalEngine, find the artifact within a cache and suddenly the code is dealing with two distinct instances of the UniversalEngine in the same area of the code.

Ideally we get this fixed somehow so that only one UniversalEngine of relevance exists at a given time.

---

Good things to explore:

• Do we need individual UniversalEngines at all? Could we use just one that we create at startup?
  • Would we lose sanboxing benefits or other nice-to-have properties if we did this?
• Would it make sense to discard the concept of engine entirely and just have Artifacts be self-contained?
  • In principle we don't care about engines much today, but…
  • Would doing so make it more difficult to implement future WASM concepts such as components?