Allow using Bitbucket Cloud API Token for authorization

[verbalius]

Bitbucket deprecated app paswords and tells users to use API tokens instead. But API tokens (for example repo api tokens) they don't work with username:password scheme where username is the bot email. This pull request changes auth to NewOAuthbearerToken if the username is x-api-token-auth or x-bitbucket-api-token-auth as Bitbucket tells in the documentation.
https://developer.atlassian.com/cloud/bitbucket/rest/intro/#app-passwords

Before the change I was always getting the 401 error (tried various combinations of email, username, personal tokens and repo tokens)

After a change it works

[matheuscscp]

We do not need to establish these special values for username in order to branch off the code to bitbucket.NewOAuthbearerToken(). The Provider API supports standalone token inputs that do not depend on a username being specified. In fact, the bitbucket provider is already using such token input and breaking it down into username and password:

	comp := strings.Split(token, ":")
	if len(comp) != 2 {
		return nil, errors.New("invalid token format, expected to be <user>:<password>")
	}
	username := comp[0]
	password := comp[1]

This is very unfortunate, because we also support username+password inputs in the referenced secret.

@verbalius How is bitbucket handling this deprecation? Has username+password stopped working completely? I ask this because I'd like to fix this code to do the right thing (if token is set, use bitbucket.NewOAuthbearerToken(); if user+pass is set, use bitbucket.NewBasicAuth()), but this would be a breaking change. The Provider API is still v1beta3 so maybe this is still possible (esp. given this move from bitbucket).

@stefanprodan Thoughts?

[verbalius]

@matheuscscp Hi, Matheus! Thanks for looking at this pull request.
Yeah I tried using bitbucket api token with email as they say in the documentation, and various other combinations but nothing worked until I did the change and built my own image and deployed to private repo for time being.
In this pull request I tried to not break any other clients that are configured in the older way if they still have the app password active (Bitbucket is still keeping them till some time of expiration, not sure by when, because I have some app passwords that don't have expiration day) but I agree that it's better to implement it better in a new way.