The HostingServiceAccountResource has always been primarily used in a

read capacity, and the implementation for create wansn't able to

create hosting service accounts for any kind of authenticated services.

There are two big issues here:

HostingServiceAccountResource.create() was manually calling

service.authorize, but with a legacy function signature that did not

  work for everything. We started the process of migrating

  HostingService subclasses to use a new credentials dict, but that

  still isn't implemented everywhere, and for services that do use it,

  the API endpoint was just completely broken.
Many HostingService instances have custom authentication forms which

  add or remove fields. These forms are what actually create the content

  of the credentials dict. In the case of the reported bug, GitLab's

  form uses a private_token field in credentials rather than

password.

This change makes it so the API resource instantiates the hosting

service's auth form and then use that form to create the

HostingServiceAccount. This makes it so we're always calling authorize

with the expected kwargs for the given service, and any custom fields

which are relied on will be properly validated and applied.
This adds a few new unit tests that use the GitLab service, since that's

an example of something that uses a custom auth form and uses

non-standard keys in the credentials dict.

Ran unit tests.