Give flat-Array-backed ComponentArrays a Mooncake tangent type

[AstitvaAggarwal]

Summary

Gives flat-Array-backed ComponentArrays their own Mooncake tangent type instead of relying on the generic auto-derived struct. Motivated by SciML/SciMLSensitivity.jl#1565, which needed a local workaround to unwrap ComponentVector's generic tangent shape. This fixes it at the source: a ComponentVector's cotangent is just a ComponentVector, so no unwrapping is needed for that code path.

Note: SubArray-backed ComponentArrays are untouched and still use the existing generic derivation.

Changes

• tangent_type/fdata_type/rdata_type/tangent: the core declaration. ComponentArray is immutable, so these need to be declared explicitly.
• The standard tangent operations Mooncake requires: zero_tangent_internal, randn_tangent_internal, increment_internal!!, etc.
• lgetfield/_new_ primitive rules, forward and reverse mode, similar to Mooncake's own Memory rule and CuArray's _new_ rule.
• to_cr_tangent/increment_and_get_rdata!: the ChainRules interop bridge.
• Test-infrastructure overrides for Mooncake's TestUtils, adapted because pointer_from_objref doesn't work on an immutable type.
• Added Random to [deps], needed by randn_tangent_internal.

Tested via

• test_rule passes, both AD modes, for identity, sum, a named-component function, and the lgetfield/new primitives directly.
• The SciMLSensitivity #1548 ODE repro produces a correct gradient end-to-end.
• setindex!, reshape, copy, similar, vcat, map, two-CV arithmetic, a real ComponentMatrix, and Complex element types all checked by hand.
• Nested/SubArray-backed access confirmed unaffected.

[wsmoses]

this seems like it uses internals aggressively and likely should be moved to mooncake proper akin to the discussion in JuliaArrays/StaticArrays.jl#1343 ?