Improve room alias management

[nvrWhere]

• modify setCanonicalAlias and setLocalAliases to prevent the same alias being the canonical and an alt alias (the server doesn't prevent this)
• add functions to connection to map and unmap aliases on the server
• add function to map an alias to the current room on the server

[KitsuneRal]

Before a detailed review, two questions:

1. The specification seems to have no opinion on whether an alias can be a canonical one and included in alt_aliases. Did you discuss it anywhere (in #matrix-spec, e.g.)? It would be great to cover this gap (if it is confirmed) to avoid different clients acting differently. And in fact, making the servers do the right changes would ultimately be the best solution.
2. No need to write the actual code but what do you expect the test for Connection::mapAlias() would look like? I struggle to find a good criteria of this operation's completion. For reference, Connection::forgetRoom(), being an orchestration of two API calls too, returns a pointer to the last job so that callers (including tests) could connect to its finished() signal. Perhaps it's worth having the same logic here - once we have point 1 sorted out.

[nvrWhere]

Before a detailed review, two questions:

1. The specification seems to have no opinion on whether an alias can be a canonical one and included in `alt_aliases`. Did you discuss it anywhere (in [#matrix-spec](https://matrix.to/#/#matrix-spec:matrix.org), e.g.)? It would be great to cover this gap (if it is confirmed) to avoid different clients acting differently. And in fact, making the servers do the right changes would ultimately be the best solution.

2. No need to write the actual code but what do you expect the test for `Connection::mapAlias()` would look like? I struggle to find a good criteria of this operation's completion. For reference, `Connection::forgetRoom()`, being an orchestration of two API calls too, returns a pointer to the last job so that callers (including tests) could `connect` to its `finished()` signal. Perhaps it's worth having the same logic here - once we have point 1 sorted out.

For 1. I have to admit this is me just pushing this the next level down from what I did in neochat and your right that ideally it should try an be resolved at the spec level as it current say nothing. I'll ask when I get a chance.

For 2. I agree as it stands right now the function does just start the job and hope. So returning the job pointer seems like the best way forward so that the errors can be checked if desired.