refactor: CustomType stores Arc<TypeDef>

[acl-cqc]

ATM CustomType::get_type_def requires passing in the Arc<Extension> from CustomType::get_extension so that the caller keeps the Arc (upgraded from the Weak<Extension> in the typedef) alive. This is annoying for callers, and the Weak<Extension> means the Extension + TypeDefs could be collected while the CustomType remains live.

Since there is no link from the TypeDef to CustomType instances thereof, we could instead

• Give CustomType an Arc<TypeDef> (but no direct link to the extension. The TypeDef has a Weak<Extension> which should be enough if really necessary.
• This requires changing Extension to store Arc<TypeDef> rather than TypeDef directly
• Drop CustomType::get_extension; remove parameters from CustomType::get_type_def

I think this is non-breaking (the CustomType methods are crate-private), might reconsider if this changes.

[acl-cqc]

I had a go at this in https://github.com/CQCL/hugr/tree/acl/custom_type_arc_2001 but found

1. CustomType has to store an Option<Arc<TypeDef>> rather than an Arc<TypeDef> to allow for serde
2. One cannot initialize this from the Weak<Extension> passed into CustomType::new
   1. that Weak<Extension> is often "nil" when we are in the middle of Extension::new_arc
   2. but becomes set when Extension::new_arc completes
   3. but we cannot make the Option become set at that time!

I see two options:

1. Store an Either<Weak<Extension>, Arc<TypeDef>> and move Left to Right at any opportunity...ugh
2. Change CustomType::new to take an Arc<TypeDef> (not Weak<Extension>): it must be possible to create the Arc<TypeDef> first (inside Extension::new_arc) before any CustomTypes referring to it (because a new TypeDef does not contain any CustomTypes, from itself or any other typedef!).

The second seems better (more obvious/explicit, less behind-the-scenes Weak-becoming-set magic, fewer Options etc.) but seems to require changing many places so this is no longer a small PR, hence I've stopped there.