OAuth consumer

Follow up of #316 /cc @cantino @alias1 @mfclarke 

Like I said my approach was to keep it really simple and it worked pretty well for twitter (the code is more of a proof of concept and not polished). The problem however is, that not every provider uses the same authentication keys. Twitter uses a `token` and `secret`, GitHub just a `token` like 37signals does. 37signals also provides a `refresh_token` which is needed to refresh the oauth token every two weeks.
So basically my "keep it simple and unintrusive" approach failed because we need at least a few different logics to store the authentication information.

Also the idea of @alias1 to have multiple account of the same provider really grew on me. Using a accounts page the user could add accounts to huginn to the services we added, marking it as global would allow every user to use the account in their agents.
I think I would not tie the registration of accounts to agents right now, for example a website agent could also use an OAuth account to access pages.

Todo list for this approach:
- [x] create the accounts model
- [x] add a services controller and the views to create and manage services
- [x] add a services drop down to the agent form and save the association
- [x] migrate the existing twitter agents to the new services model
- [x] add the ability to refresh tokens to the oauthable concern
- [x] write specs for the new controller and concern
These may need to each be on their own lines?

```
  - APP_SECRET_TOKEN=b2724973fd81c2f4ac0f92ac48eb3f0152c4a11824c122bcf783419a4c51d8b9bba81c8ba6a66c7de599677c7f486242cf819775c433908e77c739c5c8ae118d
  - TWITTER_OAUTH_KEY=twitteroauthkey 
  - TWITTER_OAUTH_SECRET=twitteroauthsecret
```