Internalize BevyManifest logic. Switch to RwLock

[cart]

Objective

Fixes #18103

#17330 introduced a significant compile time performance regression (affects normal builds, clippy, and Rust Analyzer). While it did fix the type-resolution bug (and the general approach there is still our best known solution to the problem that doesn't involve significant maintenance overhead), the changes had a couple of issues:

1. It used a Mutex, which poses a significant threat to parallelization.
2. It externalized existing, relatively simple, performance critical Bevy code to a crate outside of our control. I am not comfortable doing that for cases like this. Going forward @bevyengine/maintainer-team should be much stricter about this.
3. There were a number of other areas that introduced complexity and overhead that I consider unnecessary for our use case. On a case by case basis, if we encounter a need for more capabilities we can add them (and weigh them against the cost of doing so).

Solution

1. I moved us back to our original code as a baseline
2. I selectively ported over the minimal changes required to fix the type resolution bug
3. I swapped Mutex<BTreeMap<PathBuf, &'static Mutex<CargoManifest>>> for RwLock<BTreeMap<PathBuf, CargoManifest>>. Note that I used the parking_lot RwLock because it has a mapping API that enables us to return mapped guards.

[atlv24]

Its kind of scary that a crate dep was added that easily. I dont think it was malicious here but it shows this is a very possible attack vector. Sneak an official-sounding crate you made into macro path, then do a patch release that gets automatically picked up by cargo which has the macros insert malicious code invisibly.

[cart]

My thoughts exactly. Dependencies should be a "last resort" sort of thing, and when we take them, they should be in a trusted (known actor / high traffic / high visibility / high review) context.

[cart]

I have removed the bevy crate remapping test as it is no longer supported in this impl. I did write code to re-add support, but supporting that means scanning and string comparing every dependency (and every dev dependency) on all macro executions that don't match the bevy or bevy_x branches. We'll hit that for every macro execution in all built-in crates, in addition to the "crate alias" case. I would rather drop support than pay this compile time cost, given that remapping is super uncommon (github global search revealed zero remapped macro executions), and given that workarounds exist (see the added code comment).