As specified, resolution does some incorrect things when it attempts to resolve capture ivars (that is, ivars that are introduced by a "capture bound").

1) Capture must not produce a variable with bounds that come from a downstream assignment, the way resolution does it (e.g., given 'C<z1> = capture(C<?>)' and 'C<z1> --> C<? extends String>', resolving 'z1 = CAP extends String').  The only valid bounds for the capture variable are the wildcard bound and declaration-site bound.

2) There can be dependency cycles that mix capture ivars and normal ivars (e.g., given 'C<z1> = capture(C<? extends t>)', with some ivar u appearing in the target type, z1 -> t -> u -> z1).  We can't just resolve them all at once; we must break the cycle somehow.

3) In the case of a cycle, where there is an unresolved non-wildcard capture ivar (e.g., z2 in the bound 'C<z1,z2> = capture(C<?,T>)'), it's incorrect to generate a new capture variable for z2.  We must resolve it to T (whatever type that represents).

The picture that emerges is that we ought to be doing something that looks like: i) resolve all ivars in the to-be-captured part of the capture bound (and maybe some of their dependencies, breaking the cycle somewhere further on?); ii) perform a _real_ capture to get valid instantiations for the capture ivars; iii) continue with resolution.

An example of a cycle:
<T> C<?,T> makeC();
<U> void take(C<? extends u, ? extends u> arg);
take(make());
// C<z1,z2> = capture(C<?,t>)
// z1 -> t -> u -> z1