Add actor alias feature

[Joe Stubbs]

Add support for a new collection, aliases, that map user-provided identifiers (an "alias") to an existing actor_id. Once an alias is created, all endpoints involving a specific actor can be accessed with either the alias or the actor_id. For example, if a user creates an actor with id rljRykvYRawLO and then creates an alias jane to that actor_id, the following routes and all sub-routes would be equivalent:

/actors/rljRykvYRawLO
/actors/jane

The alias must be unique across the tenant. The service will create an internal alias_id from the alias and the tenant, similarly to how an actor's db_id is created. It will follow that the alias_id will be globally unique. We'll use the technique suggested and implemented by @mwvaughn to distinguish actor_id's from aliases by attempting to decode an identifier with the Abaco salt. Aliases will not be allowed to be Abaco hashid's (i.e., a hashid produced with the Abaco salt).

Aliases will have separate permissions for managing the alias definition itself. Access to an actual actor endpoint will still be governed by the actor's permissions: alias permissions are only used to govern who can manage the alias definition.

New endpoints -
/actors/aliases:

• GET - list all aliases
• POST - create a new alias. Required fields are actor_id and alias

/actors/aliases/{alias}:

• GET - retrieve details about an alias.
• DELETE - delete an alias

/actors/aliases/{alias}/permissions:

• GET - list permissions associated with the alias.
• POST - add a permission to an alias. Required fields (user, level) the same as actor permissions.

[Joe Stubbs]

Released in 0.12.0