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
Unix shells cannot read or write an environment variable which name starts with a number, but is it OK since no one would inject these variables via a shell script?