Migrate localpart-only columns to full MXIDs

This issue has been migrated from [#15396](https://github.com/matrix-org/synapse/issues/15396).

---

`profiles.user_id` and `user_filters.user_id` (are there more?) currently store localparts only, which is inconsistent with the rest of the schema. We'd like to move to storing full MXIDs.

### The plan
The migration will happen over two schema versions.

**Current schema version +0**
Can use databases up to and including schema version +1.

**Schema version +1**
Add a new column, called `full_user_id`, which is nullable and unique.
Add background update to populate it.
Modify reads to query both the localpart and full user IDs (localparts can't include `@`s or `:`s and so can't be confused with a full MXID)

Can use databases up to and including schema version +2.

TODO: we need to modify reads to `user_id` to check for both the full MXID and localpart, to work with schema version +2. Reads and writes should not touch `full_user_id`, otherwise Synapse won't be compatible with schema version +2, where there is no longer a `full_user_id` column.

**Schema version +2**
Force the background job to complete
TODO: figure out how. We may have to duplicate the background job logic in the schema migration.
NB: just because the background update has finished does not mean that `full_user_id` is fully populated. The server might have been rolled back to a previous Synapse version after it completed.
Make `full_user_id` non-nullable (see @\reivilibre's comment below about avoiding table locks)
Drop `user_id` and rename `full_user_id` to `user_id` in a schema migration.
Unqueue the background job, just in case it hasn't run yet/is still in progress.
Update reads to only query for the full user ID.
For this step, we want to audit usages of both `{profiles,user_filters}.user_id` and `{profiles,user_filters}.full_user_id` since there are still some reads that only use the old `user_id`.

Update `SCHEMA_COMPAT_VERSION` to schema version +1.
ie. code expecting schema version +0 or later cannot use the database, but code expecting schema version +1 or later can.