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:
- [ ] create the accounts model
- [ ] add a accounts controller and the views to create and manage accounts
- [ ] add a accounts drop down to the agent form and save the association
- [ ] somehow expose the account to liquid so it can be used in generic agents
- [ ] migrate the existing twitter agents to the new accounts model?