Adds doorkeeper to allow application to authenticate against huginn

This should help with #626, it also has the benefit that users do not need to share their username and password with any third party application that needs to access the huginn instance.

Since we probably can not keep the application `secret` secret I think we should automatically add every known application that is able to use huginn via a migration.

At the moment you need to access `<your huginn instance>/oauth/applications` and add the application manually.
> It seems like maybe oauth2 isn't as good as I was thinking for Huginn, because what we mostly need is just token-based authentication.

I had the same feeling after we discussed the potential issues. OAuth is nice, but does not seem to fit our needs well.

> Maybe all we really need is a page where you can make any number of API tokens, each with a memorable random multi-word secret, optional expiration date, and name. Then you can hand one of these to any app along with your Huginn URL?

Do you mean the user provides both the token and the secret or either of them?

To create a token authentication which is as secure as possible, I see two options:
* issue a token (a cryptographic hash to guarantee randomness) and the email/user_id (or a hash of it) 
* show the token once and store a hashed version it (should be immune to timing attacks and thus not need the email/user_id to mitigate the attack)

If we agree that we can live with potential timing attacks the 'random multi-word secret' options would be kind of neat.