Support cycles in encoders

[Aurel300]

The task encoder framework now supports cyclic dependencies (better).

Previously, requesting the same task key that is already higher up the call stack would crash with a "cyclic error". There are situations (as happened with a recursive type) where this is not good enough.

Now, the repeated request will restart the encoder. The inner invocation should be able to progress further due to the intermediate dependency calls, since additional output refs will be available. The outer invocation will be aborted. This may result in some data being allocated multiple times, but it is hard to measure the cost here. However, the overhead in implementation is minor: deps.emit_ouput_ref and any deps.require_* call simply needs to be handled with a try operator ? to propagate errors.

Other changes:

• There is now a type alias for the return type of do_encode_full, called EncodeFullResult<'vir, E>, where the generic type parameter is the encoder itself.
• Got rid of the 'tcx lifetime, 'vir suffices.

[Aurel300]

@zgrannan Could you have a look at this? With this code I get an error which seems to be related to generics:

struct R(Option<Box<R>>);
fn main() {
    match R(None).0 {
        Some(_) => (),
        _ => (),
    }
}

Predicate p_Option could not be applied. Expected arg types: UnknownArityAny([Ref, Type]), Actual arg types: [Ref]

[zgrannan]

It looks like it was due to not including type parameters in the predicate application.
I've fixed this in the impure_generics branch with cf05f4f; I also refactored a little bit to make it harder to accidentally forget them in the future.