Make `a.b()` always a method call, refactor how methods are represented in the compiler

[nikomatsakis]

We have agreement that the syntax expr.m() will always represent a method call (and never a call to the field expr.m). This allows us to make a change to the compiler AST so that we have expr_mcall() (method call) and not expr_call(expr_field()), which in turn allows various other simplifications in borrowck, trans, and elsewhere. In the process---or, perhaps, as first steps---I want to do some smaller refactorings:

• Represent vtables as a tree and not the current flattened representation. This will simplify code all over the place.
• Remove the callee_id and just hang method information off in different tables (this basically requires an expr_mcall)
• Maybe: change how operator overloading is implemented so that, from the front end's point of view, all overloadable operations are method calls, but some of them call "intrinsic" methods. Constant expressions are therefore restricted to such intrinsics, and of course trans will generate a+b the same way it does today.

[bblum]

I was going to ask, wouldn't that make it impossible to call one-shot functions inside of structs? But that wouldn't make any sense anyway - if you don't have some way to move the oneshot out of the struct (such as would be needed to call it under this agreement), then you have no way to consume the oneshot to begin with.

I forget, did we decide that noncopyable closures were the same as oneshot closures, or not? If not, there might be that issue here.

[nikomatsakis]

@bblum I don't think this issue creates any fundamental limits. You can always write (a.b)() to call a closure that's stored in a field. It's just that the a.b in a.b() will not be parsed as a field.

[bblum]

ohh, ok. yeah.

[catamorphism]

Mostly completed by @pcwalton . Some of the auxiliary changes may not be finished.

[pcwalton]

Fixed