Currently, if you were to call (for instance) write_value as part of a custom write_host_object implementation, you would be forced to create aliased exclusive references to the serializer (which is instant UB).
The underlying v8 de/serializers are re-entrant, so for the most part we simply need to pass around shared references instead of exclusive references.
Also adds some bindings to some missing functions, and makes ValueSerializer (and deserializer) garbage collectable.
* Rolling to V8 12.9.202.1
* initial changes for 12.9
* CallbackScope for fast fns
* disable broken thing by default
* use windows 2022 runner
---------
Co-authored-by: snek <the@snek.dev>
A subtle unsoundness / undefined behaviour made its way into the fairly recently added ExternalOneByteStringResource object: The as_str API is not sound as the data inside may be be Latin-1, not ASCII.
As the API was not used anywhere in deno or deno_core, I opted to simply remove it and replace it with an as_bytes API. I also modified the test to showcase the Latin-1 string case and added copious notes and explanations around the code to make sure this doesn't accidentally happen again. The likely reason why the API originally slipped in is because the OneByteConst has this API where it is safe because the OneByteConst creation checks the data for ASCII-ness.
I also tried to add an API to extract an Option<&'static OneByteConst> from an &ExternalOneByteStringResource but run into rust-lang/rust#119618 ie. OneByteConst is actually duplicating the vtables... which is not great.
