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
Ah, right totally forgot the migrated names. I think it would be nice get rid of those strange names, but also unsure if it is worth adding the code since the only "real" use case are the migrated twitter accounts. @cantino what do you think?