Omnigraph: Migration & Reservation

[shrugs]

Index the migration controllers and surface the state of a domain via the api, with a focus on ergonomics. Note that the current domain interface handles differentiating between a v1 and a v2 domain, and so for migration status, nuance between the two is desired. perhaps a Domain.migration meta field.

in #1845 basic reservation was implemented, but further thought needs to occur related to the addressing of unregistered domains. in particular, addressing a domain needs to take into account registration status (i.e. whether it is fully expired) and prefer a v1 name to an expired v2 name, depending on how the ENSV1Resolver and ENSV2Resolver handle those cases.

additionally, if a v1 and v2 name both exist but the v2 name is reserved, then it is the v1 name that is the correct domain to give the user (at the omnigraph api level), because while the v2 name is technically the domain that would be resolved, it would proxy resolution to the ENSv1 version o the name using ENSv1Resolver. More specifically, if the v2 domain for a name has as its resolver the ENSv1Resolver then it's the v1 name that is canonical and should be returned by the omnigraph resource api.