Due to a bad design choice a long time ago, we based hosting service IDs

off their names. Names are used for display, but we used them for IDs as

well, despite the fact that they frequently contained characters (such

as capital letters and spaces) that were not valid for some of the URLs

served up in the API.
The built-in services (which used entrypoint names for IDs), or those

custom-registered using register_hosting_service() (which takes a

"name" for the ID), did not have this problem, but ones using

HostingServiceHook did.
Now, HostingService supports an official hosting_service_id

attribute. HostingServiceHook will respect this, but if it's not set

(likely the case with any custom implementations using the hook today),

it will have one set automatically based on the name (using Django's

slugify(), which transforms to the exact same set of characters our

URLs allow).
register_hosting_service() still overrides the ID with the "name" that

is passed, in order to stay compatible with existing behavior. This is

important to avoid breaking some implementations that have hosting

services subclassing other hosting services (as an ID might be set on a

base service before it's set on a subclass, breaking registration if not

overridden).

Unit tests pass.