[turbopack] Adopt inventory for our registry (#83074)
## What?
Leverage the `inventory` crate to automatically register turbo tasks objects using specialized linker sections. See https://docs.rs/inventory/0.3.21/inventory/ for details
For NativeFunction and TraitType objects this was trivial and simplified the registry, for example.
* functions only need the global registry during PC _deserialization_ so many builds can skip the cost.
* Even when we do allocate it, we can use a normal `HashMap` instead of a `DashMap` which should be a minor performance benefit on its own (no locks, smaller in ram)
* TraitType objects achieve similar benefits.
The tricky part of course was trait impls:
* Every `ValueType` needs to know all the trait methods it implements
* To support calling `turbo_tasks::functions` on `Vc<Box<dyn T>>`
* every `TraitType` needs to know all the structs that implement it
* To support dereferencing a trait ref, aka `TraitRef<Box<dyn T>>` -> `&dyn T` to support calling non-turbotasks functions
This required two more registries which more or less followed the existing pattern. One benefit of the new `inventory` approach is that the `VTableRegistry` drops its interior mutability (and associated locks). Constructing VTableRegistry objects also becomes lazy which is useful since many are not needed.
So overall this should be equivalent but slightly better and it allows us to drop the build scripts (See #83156 )
One interesting note is determinism of `TraitTypeId` and `ValueTypeId`. Previously the values assigned were determined by the order of registrations in the build script. With inventory they are registered in an undefined order (im guessing it is deterministic based on linker input order, but inventory makes no guarantees). As far as i can tell, this does not matter, but in the interest of determinism i have sorted the values based on their names. In the future we can use this determinism to optimize persistence
## Why?
By colocating registration with the proc macros we can simplify the registration logic. Switching to 'pull' based registration also simplifies a number of datastructures and allows us to drop some RWLocks
## Interesting consequences
All the global type names are changing, dropping the `@TODO::`
This `TODO` was a placeholder for a content hash of the current crate. This is to support a hypothetical idea where at least some of the persistent cache could survive turbopack updates. However based on team discussions we don't currently see a clear solution here. If we want to do this in the future i think we could still leverage hashes in names but we would need to compose them in a different way (e.g. `build.rs` script sets an `env` var that the proc macro reads with the `env!` macro)
