Previously, `ast::Resolve` would sometimes assign a `Stability` to types
according to the first function it found that type in as a parameter or result.
That's a problem if such a function is marked `@unstable`, since it will
effectively poison that type and prevent it from being used by any other
function -- even if the type itself is ungated.

This fixes the problem by removing the `&Stability` parameter from
`resolve_params` and `resolve_results` and instead passing `&Stability::Unknown`
to `resolve_type` from those functions.  Additionally, I've added a new
`find_stability` function which recursively inspects a `&TypeDefKind`, looking
for a non-unknown stability.  If it finds one, it will use that; otherwise, it
will default to `Stability::Unknown`.

For example, if `option<T>` appears as a parameter type in a function, we'll
start by assuming that type has unknown stability, then look to see if `T` has a
stability (directly or transitively) and use that if so.  Things get interesting
in the case of e.g. `tuple<T, U, V>`, where `T`, `U`, and `V` each have their
own stability.  Currently we just use the first known stability we find, but
perhaps there's a better approach to consider?

Signed-off-by: Joel Dice <joel.dice@fermyon.com>