Use absolute paths in procedural macros

[DavidCrossman]

Objective

• Improve procedural macro hygiene. Follow-up to Use absolute paths in ECS macros #23718.

Solution

• Use absolute paths in all procedural macros.

Testing

• Ran cargo run -p ci -- compile

Notes

• I've qualified Vec as ::std::vec::Vec in the AsBindGroup derive because bevy_render requires std. If bevy_render supports no_std in the future, this will need to be changed to use the __macro_exports strategy used by bevy_ecs and bevy_reflect. Perhaps bevy_macro_utils itself could export no_std compatible paths for alloc types like Vec and Box to avoid repeating the same strategy in every crate which generates alloc types in macros.
• I haven't used absolute paths for primitives (::core::primitive::bool vs bool) since even serde doesn't, but I can do so in this PR if desired.

[alice-i-cecile]

I like the notion of this in general, but can you explain why the FQ types are better than the core types here? Shouldn't core always be available?

[DavidCrossman]

I like the notion of this in general, but can you explain why the FQ types are better than the core types here? Shouldn't core always be available?

I'm following the precedent set by bevy_reflect; it uses the FQ types whenever possible. I've used the FQ types in bevy_ecs and elsewhere for consistency.
Personally, I think the FQ types are a little nicer since ::core::... in quote! is noisy, and it's easy to forget the leading :: in the path. The FQ types expand to ::core::... anyway (they are never in the expanded code). However, I think that FQBox is problematic and should be removed/reworked since it expands to ::std::boxed::Box and can't be used in no_std. FQBox is currently unused in the codebase. If bevy_macro_utils had a __macro_exports module, then FQBox could expand to #bevy_macro_utils_path::__macro_exports::alloc_utils::Box, which would reduce a lot of noise in quote!s in bevy_ecs and bevy_reflect.

[Breakdown-Dog]

Would it make sense to introduce an  FQFnMut  here, similar to other FQ types used elsewhere?

[DavidCrossman]

I'm not sure what the policy should be for adding new FQ types; adding every type in core/std would be excessive, so just the ones we use? I added FQIterator and FQInto because they appeared a few times (Iterator 6 times, Into 9 times). I could add FQFnMut, since FnMut appears 3 times, but I would also need to add FQFn (appears once) and FQFnOnce (doesn't appear) for parity.

I'd like to keep changes to the fq_std module small in this PR, as the focus is fixing hygiene issues. I think the module could be improved (FQBox in particular) in a later PR focused on code quality.