…ed` with those of `next()` on adapters that have both.

It improves the performance of iterators using unchecked access when building in incremental mode
(due to the larger CGU count?). It might negatively affect incremental compile times for better runtime results,
but considering that the equivalent `next()` implementations also are `#[inline]` and usually are more complex this
should be ok.

```
./x.py bench library/core -i --stage 0 --test-args bench_trusted_random_access

OLD: 119,172 ns/iter
NEW:  17,714 ns/iter
```

…garing

…n cleanup on drop

The on-drop cleanup will enable using TRA in try_fold(&mut self) and implementing TRA for &mut Iterator

This removes all TrustedRandomAccess specialization from Zip, which means Zip::next no
longer gets optimized as well. But since for loop desugaring uses TRA we retain most of the benefits.

We're still losing optimizations on fold, try_fold and reverse iteration. But those can
be re-specialized more easily.

…::try_fold

Previously these optimizations automatically fell out of the default implementation for `fold` and `try_fold`
because `next()` was specialized. Since that is gone we now need to implement it explicitly.

TRA is no longer used for single-step (`next()`) specializations, only loops and after each
loop we bring the iterator back into a safe state, meaning coercions are now safe because
the user code will not have access to an iterator instance that would be unsafe to coerce.

…al the need for pre/post loop calls

The loop setup and cleanup functions are only required for some specific iterators.
To avoid emitting IR when they're not needed even in debug mode we need to use the type system
instead of const-DCE because the constants would only be known after monomorphization.

This reduces the amount of IR generated when post-loop cleanup is needed