Consider a new interface for Enums

Nobody has claimed this yet.

The ability to use enums in your models is pretty nice, but the current interface did require a small bit of hacking around some of the type restrictions. This has led to using enums being a bit difficult.

Here's the current interface:

```crystal
class GameEvent < BaseModel
avram_enum Type do
Connected
Started
Ended
Disconnected
end
table do
column type : GameEvent::Type
end
end

SaveGameEvent.create!(type: GameEvent::Type.new(:connected))
GameEventQuery.new.type(GameEvent::Type.new(:connected).value)
```

Here's a few of the issues I've found with this setup:

1. The migration requires you to know to create your column type as the Integer. `add type : Int32, default: 0`
2. The model column definition requires the model namespace due to macro stuff. `column type : Type` would fail (probably with a not so pretty error)
3. Saving the enum value requires instantiating this magical class, but querying requires the raw int value
4. If you have a lot of enum members (say 26 like I have in my app), then running SQL and seeing 17 means nothing. (This is more of a preference deal, it may just be a "you're using enums, deal with it" type situation)
5. Getting the enum member is a bit error prone. If your enum member is multi word, you define it like `ControllerActivated`, but to get the value, you either need to use `"ControllerActivated"` or `:controller_activated`. If you use `:controlleractivated`, then you get a pretty bad error that doesn't tell you why. The same goes for if you did `:contoller_activated` (misspelled controller).

Along with 5 https://cdn.discordapp.com/attachments/743896265057632259/862356608227344427/unknown.png You'll see here it says you can't pass a Symbol. That's because Crystal autocasts Symbol to enum when it matches, so in that case `:super_admin` is treated more like an enum as where `:superadmin` is treated like Symbol. If you're new to Crystal than this is super confusing.

As for how we solve this, I have no clue... Postgres does support enums directly https://www.postgresql.org/docs/10/datatype-enum.html If we decided to go that route, it would solve 4, but that also means that anytime you wanted to add a new enum member, you'd always have to generate a migration. Adding a new one to your model without the migration would cause issues. Maybe that could be caught by the SchemaEnforcer?

Another option could be to maybe have an alternate column macro... So it could look like this:

```crystal
class GameEvent < BaseModel
enum Type
Connected
Started
Ended
Disconnected
end
table do
enum_column type : Type = Type::Connected
end
end

SaveGameEvent.create!(type: GameEvent::Type::Connected)
GameEventQuery.new.type(GameEvent::Type::Connected)
```

In this case, we couldn't call the column macro "enum" due to conflict with the actual `enum` keyword. We'd also forgo the ability to use Symbols or Strings because having a typo with the constants would allow for better error messages.

I have no clue if this would even work, or how the code would look, but I wanted to get the conversation rolling and allow others to chime in with some thoughts on this.

Start with the existing avram_enum and column macros, then review migration handling and the SchemaEnforcer mentioned in the issue. Compare the proposed enum_column API and PostgreSQL enum option against the five listed pain points; done means an agreed interface and implementation scope that resolves them or clearly defines their trade-offs.

Written by the indexing model from the issue text.