rework scopes to make them stack allocated and remove runtime bookkeeping of scopes

[nathanwhit]

Before this PR, HandleScopes (and other scope types) were stored in the heap and we did bookkeeping at runtime of the current stack of scopes. The reasons were primarily:

• raw handle scopes need to be pinned in memory once initialized
• we couldn't enforce at compile that a Local didn't outlive the scope it was created from
  The latter lead us to need a workaround where scopes actually were not exited when they were dropped, rather they were exited the next time we activated another scope.

This PR refactors the scope implementation to:

• make scopes stack allocated, to reduce overhead of using them
• remove the runtime bookkeeping
• use lifetimes to prevent scopes from being dropped, so we can remove the zombie scope workaround

The practical effect is that creating a handle scope changes from:

let mut scope = v8::HandleScope::new(&mut isolate);
let local = v8::Integer::new(&mut scope, 123);

to:

let scope = std::pin::pin!(v8::HandleScope::new(&mut isolate));
let scope = scope.init();
let local = v8::Integer::new(&scope, 123);

// or shorter
v8::scope!(let scope, &mut isolate);
let local = v8::Integer::new(scope, 123);

If you accept a HandleScope as a parameter in a function, you would change it from:

fn takes_scope(s: &mut v8::HandleScope) {}

to

fn takes_scope(s: &mut v8::PinScope) {}

(v8::PinScope is a type alias for a pinned handle scope).

[devsnek]

overall this seems alright, but we should probably wait until we are near cutting another major release to merge it.

[bartlomieju]

We talked about this PR during the meeting - we'd like to first fix Homebrew build and Windows debug symbols (denoland/deno_core#1191) before landing this one.

[nathanwhit]

Calling out these changes, as they're sort of orthogonal to the scope stuff and somewhat buried.

The idea is to only ever have raw pointers pointing to the actual isolate, and never create references to it. This allows us to avoid the aliasing invariants that would come with having an &mut RealIsolate. It also means that if the C++ does mutation through a the pointer, it is well defined even if the pointer came from an &Isolate.

Now, Isolate is just a wrapper around the raw pointer. We can still get the borrowing semantics we want, it's just a &mut NonNull<RealIsolate> instead of &mut RealIsolate. The only way to get an Isolate is from Isolate::new or unsafe code via UnsafeRawIsolatePtr (maybe should rename that)

[littledivy]

LGTM!

[bartlomieju]

LGTM, can you please address TODO from the description before landing?

Let's cut 140.2.0 after this is merged and update deno_core.

[littledivy]

LGTM