Add initial support for composite primary keys

[sgrif]

This pull request allows the table! macro and codegen to handle tables
which use more than one column for their primary key. At the moment they
are fairly useless, but they will compile.

The methods in question are primarily used for FindDsl and
associations. Things like update are defined in terms of FindDsl and
Identifiable. Since the generators for those traits don't handle
composite primary keys, none of that can be used (yet).

Working on this also made me realize a bit of a hole in our type system.
We implement Expression for a tuple of expressions as a comma
delimited list. However, a comma delimited list isn't always valid. In
particular a composite table does actually implement FindDsl for an
expression that matches it's primary key -- and would generate invalid
SQL like pk1, pk2 = $1, $2. Luckily, we're saved by the fact that
tuples don't implement AsExpression, so trying to do .find((1, 2))
won't compile.

I'm not sure if we should fix this or not, but the fix would basically
mean separating out "arbitrary expression" from "expression valid as a
select or returning clause", and potentially other places where tuples
appear such as set clauses and in expressions. For now though, as long
as the inproper code doesn't compile for the reasonable cases, I'm not
super worried. We should fix this eventually though, as I don't like
something that we can statically determine is invalid SQL compiling.

Ref #42

[sgrif]

Review? @diesel-rs/contributors

[killercup]

LGTM. Do you maybe want to add some docs on how to use this? (Mentioning that the table! macro allows a comma separated list of columns for composite primary keys should suffice.)

[sgrif]

(I added docs before merging)