[GSoC] Rust: Compiling the alloc crate - Status Report 4

Hi!
This is the fourth report on compiling the alloc crate with GCCRS.

This week I set out to:
- Investigate the issue blocking the 'coerce_unsized' lang item
   implementation.
- Register async/generator lang items.
- Expand the alloc testsuite.

Over the week:
- I opened issue Rust-GCC/gccrs#4678 regarding the 'coerce_unsized'
   problem and put it on hold for now. I will revisit this in the coming
   weeks.
- I completed the alloc testsuite. We can now compile the entire alloc
   crate with the '-frust-compile-until=nameresolution' flag. Currently,
   I am using a mock core module, designed as a submodule of the library,
   to provide the core structures that alloc needs. You can review the
   state of the testsuite here: (Rust-GCC/gccrs#4693)
- During compilation, I discovered some additional missing items
   (attributes, lang items, and features) that I hadn't encountered 
during
   my initial investigation.
- I registered the missing attributes as stubs.
- I implemented the 'assert_zero_valid' intrinsic.

Note: For any missing element (lang item, intrinsic, attribute, etc.),
a full implementation is always the primary priority. Even if a full
implementation is completely blocked by infrastructure limitations,
deciding to register it as a stub requires careful thought and
discussion. If something is registered as a stub, you can be certain it
is a deliberate and well-considered decision.

Current status:
- The primary priority right now seems to be registering the 4 missing
   lang items:
   'range_inclusive_new', 'pin', 'unpin', 'unsafe_cell'.
- In parallel, I am working on compiling the mock core module as a
   library so we can use it as an extern crate. Currently, full
   compilation of the mock core is failing due to some complex trait
   bound usages, which is why it is still defined as a submodule.
- This submodule approach has some negative impacts. First, we are
   forced to add prelude imports to the alloc code, which is the worst
   part since our goal is to mutate the alloc source code as little as
   possible. Second, our current compilation bottleneck
   (until=nameresolution) is coupled with the mock core. Because they
   are compiled together, when the compilation stops at the name
   resolution phase, we cannot isolate the cause. We don't know if it's
   actually alloc failing, or if alloc could compile further but is
   being blocked by mock core's failures. This lack of isolation is a
   major disadvantage.
- Although it is not strictly part of this week's immediate targets,
   the 'coerce_unsized' issue remains the next major milestone.

Best regards,
Enes