Omniauth refactors

Hey @dsander, here are some minor changes to your branch.  Mostly just me thinking in code, so feel free to challenge any of them, especially allowing unknown providers.

I also have a few questions / thoughts:

1) I don't fully understand what the `.oauthable-form` class JavaScript logic is doing.

2) Your upgrade code makes sense.  Would it also be good to allow backwards support in the Twitter agents like this:

```ruby
ENV['TWITTER_OAUTH_KEY'] || options['consumer_key'].presence || credential('twitter_consumer_key')
```

Or is that unnecessary?  The same thing could be done in the BasecampAgent to avoid breaking on upgrade.

3) What is the use case for granting other Huginn users access to your data on a given service?  I don't think I fully understand this.

4) Should we use JSONSerializedField for `serialize :options, Hash` in Service?  (Maybe there's no benefit at all.)

5) Based on the presence of `@@provider_to_env_map` (now `PROVIDER_TO_ENV_MAP`) and `provider_specific_options`, perhaps we should be using subclasses of Service to handle differences?  Maybe not needed yet?

6) In your upgrade migration, what if a user's Huginn instance is using multiple Twitter applications?  (Seems unlikely, but it's possible.)  We could check that `agents.map { |agent| twitter_consumer_key(agent) }.uniq.length == 1` and warn otherwise?

This is about 3), you can not grant other users access to your data, you can just allow them to use the oAuth application you registered with the provider. The idea behind this is that the administrator of the huginn instance sets up oAuth applications for the providers and the users authenticate their account against this application.