Refactoring: cleaner tree node interface

[nikomatsakis]

We currently have these dada_id macros for creating the internal IRs. I dont' even know if they're documented anywhere in particular, but the idea is that you have a

• tables -- maps from the id of a node to its data
• origins (or spans) -- maps from the id of a node to its origin (e.g., span for a syntax tree, but we link BIR nodes to syntax tree nodes)

Creating a new node in this setup is kind of tedious. You have to create the id:

id!(pub struct Foo);

then declare a data

pub struct FooData { ... }

implement DebugWithDb in this weird way, and then add those entries to two big macros, which in turn create various traits that allow you to do things like foo.data(tables) (or tables[foo], I haven't decided which I like better) and foo.origin_in(origins) (or `origins[foo]).

I think we can make this a LOT cleaner. I'd like something lke

/// declare each kind of node, along with its "data" type and origin, here in one consolidated place
declare_ir! {
    (Expr, ExprData, Span),
    (Name, NameData, Span),
    ...
}

// declare the data structs separately
#[derive(...)]
struct ExprData { .. .}

and then probably pick one way to get data. If we adopt anchored spans (see #212) then we can be less careful with how we store data/spans (right now, I try to put spans in another field of a tracked struct, so that we don't "see" them unless we report errors).

I suspect the right answer is to have that macro generate a Ir struct and let you do expr.data(ir) and expr.span(ir), though ir[expr].fields is also appealing (the Index trait doesn't permit expr[ir].data, which I think I would like best).