`insert` is inconsistent, and should be changed to match other operations

[sgrif]

This is just an artifact of the fact that I implemented this before everything other than the most basic forms of select. This should be changed to match update and delete. This is the API I'm imagining:

insert_into(table).values(records)

This would return a command that can be used in the same way the return values of update and delete, which will be less painful with #29.

Since this represents a breaking change in one of the most common APIs, we should do this sooner rather than later.

[mcasper]

How would we feel about reversing the order?

insert(record).into(table)

It feels more consistent to me with update and delete, which both seem to follow the pattern of

action(record).action_specific(parameter)

So we would be left with the API

insert(record).into(table)
update(record).set(changes)
delete(record)

[sgrif]

Would it though?

update(users.filter(id.eq(1))).set(user_changes)
delete(users.filter(id.eq(1))
insert_into(users).values(new_user)

vs

update(users.filter(id.eq(1))).set(user_changes)
delete(users.filter(id.eq(1))
insert(new_user).into(users)

there's also the third option (not mutually exclusive)

new_user.insert_into(users)

[sgrif]

I do want to end up supporting update(record) and delete(record) as sugar for filtering on the PK though, so there's merit to insert.into. It also reads more naturally.