**Description:**
I just realized there could be some case who'll want plugin in native env, but without filesystem cache. If there's a custom cache implementation, it'll make a conflict to swc's caching mechanism since swc does not expose any interface to the its cache.
PR takes simple approach to expose another feature to opt in native env with memory cache for those case. Ideally we should make `plugin_transform_host_native` to not to opt-in any cache, and then make `swc_plugin_runner` to run without any cache implementation - but that'll be a breaking changes with few more involved changes.
**Description:**
Second attempt to enable bytecheck. This PR does not have versioned struct yet, just enabling bytecheck wherever possible. Also, it is for the ast only yet, so transform metadata and others might need this later.
PR seems to be passing all the ci, but as we've experienced before, there might be some unexpected outcomes with the release. Maybe better to hold this until clear https://github.com/swc-project/swc/issues/7238, then land as a separate release.
**Description:**
Previously disabled cache (storing compiled module in memory) still doesn't work, so falling back to storing raw bytes and create new module each time. This is the same behavior to the wasm build's approach.
Also minor improved caching root to include more information. Previous rustc didn't seem to work unfortunately, so removed but instead using plugin_runner's version.
**Description:**
Attempt to workaround #7238.
Originally I thought this is related with oom or memory layout, then realized actual deserialization error occurs in weird position - it tries to deserialize BytePos (which is obvious type) and it fails. It made me think maybe a property next to the struct layout have some unexpected behavior, notably Arc<String>.
PR applies same workaround as Atom does, and it seems to at least pass swc-coverage-instrument's usecases. May need bit more verification with other plugins to see if we can call this out as reliable workaround.
