RFC: clean up method reflection

[JeffBezanson]

This does a few things to improve the results from methods, and clean up some internals:

• Adds back the sig and tvars fields to Method. Although technically redundant, this makes Method more intuitive for describing a method definition.
• Removes most uses of TypeMapEntry in reflection, de-coupling the method cache representation from anything user-facing.
• Fixes REPL: Tab completion for a type throws a MethodError #16042 in passing.

Finally, we had a problem where methods(f) returned a full MethodTable (except sometimes!), but methods(f, t) returned an array of Methods. Those types are printed differently, plus we are only able to show keyword arguments if we have access to the MethodTable, due to how kwargs are implemented. We could always use MethodTable, but it's not iterable and building one is a very non-trivial process just for showing a list of methods.

To address this I added a MethodSet type, so we can return any subset of methods with a consistent interface and printing. This solves all of the problems, but I don't quite love it, so suggestions are welcome.

This could be used in methodswith as well, except that it can return methods from multiple functions so it doesn't quite fit.

Another option would be to return matches from a function's keyword arg sorter as well, so you'd get 2 entries in a returned array for each method with keyword args. The downside is that these are not really methods of the same function, and have non-obvious argument lists.

[iamed2]

For use of method reflection in the wild you can look at https://github.com/invenia/Mocking.jl. We needed first so I implemented iteration for MethodTable. There's also some signature-parsing shenanigans that were using TypeMapEntry here: https://github.com/invenia/Mocking.jl/blob/master/src/signature.jl#L33

[JeffBezanson]

I'm not sure that definition of iteration for MethodTable is correct any more.

Thanks for pointing me to this --- it's truly scary how an internal change leaked to a package within a matter of days. This is exactly why this PR is needed. You should not need to use TypeMapEntry; the representation of a cache is as subject to change as anything I can think of.

[JeffBezanson]

To expand a bit, I think it makes sense to have a Method type that (surprise) describes a single method, for the foreseeable future. Even if it is no longer used internally, we can continue to return Method objects for reflection. Some other types, like TypeMapEntry and MethodTable, are more ephemeral.

[vtjnash]

doesn't matter now, but eventually we should delete this line (it's been a no-op ever since inference0.ji was eliminated)

[vtjnash]

lgtm

[stevengj]

<: AbstractSet{Method}?