Updated Migration DSL

This is an updated version of #132.

TODO

- [x] Add more column types (boolean, decimal, etc..), currently only primary key, varchar, datetime, integer
- [x] Add `timestamps/0` function to DSL (maybe this should be a separate PR, since the models should support this notion too)
- [x] Shortcuts for `alter table(..)` (add_column, remove_column, modify_column, rename_column)
- [x] Existence functions (column_exists?, table_exists?, index_exists?)
- [ ] Support old string-based migrations by checking return value, not sure if this is needed because old migrations can be updated to use `execute/1`
- [ ] Column options, `default`, `scale`, `precision`, others?
- [x] Add `references/1` for creating foreign keys i.e.

```elxir
create table(:products) do
  references(:category)
end
```

It supports a DSL syntax, for creating/dropping/altering objects:

## Change Example:

```elixir
defmodule Repo.Migrations.CreatePosts do
  use Ecto.Migration

  def change do
    create table(:posts) do
      add :title, :string
      add :published_at, :time
    end
  end
end
```

## Up/Down Example:
```elixir
defmodule Repo.Migrations.CreatePosts do
  use Ecto.Migration

  def up do
    create table(:posts) do
      add :title, :string
      add :published_at, :datetime
      timestamps
    end
  end

  def down do
    drop table(:posts)
  end
end
```

## Alter Example:
```elixir
defmodule Repo.Migrations.AlterPosts do
  use Ecto.Migration

  def change do
    alter table(:posts) do
      add :summary, :string
      remove :published_at
      modify :title, :string
      rename :owner, :created_by
    end
  end
end

```
The `create` and `alter` implementation should not collect the `block` expression. For example, this code is invalid:

    create table(:posts) do
      add :title, :string, default: "Untitled"
      add :body,  :text
      if some_condition? do
        timestamps
      end
    end

What you should do instead is to have each of those actions push information to the GenServer, which will collect and normalize all instructions. For example, create should compile to something like:


    defmacro create(what, block) do
      quote do
        Runner.push_context(what)
        unquote(block)
        Runner.pop_context
      end
    end

Once the context is popped, you send it to the adapter to the execute it. From the adapter perspective, the data structure it will receive will be the same, but it will allow dynamic values. :)