Resolution API: Further constrain the type of names used for resolution

[shrugs]

InterpretedNames are technically not resolvable because the ens contracts are not encoded-labelhash-aware.

We likely want/need a new branded type (dns-encodable name? resolvable name? standard name? regular name? normalized name?) that has the following constraints:

• it may contain encoded-labelhash-looking segments but label segments will NEVER be interpreted as perhaps being an encoded labelhash
• no label segment has byte length greater than 255 (because dns encoding)
• A: all label segments should be normalized (?)
  • so this is basically a NormalizedName, since [ and ] are not normalizable
• B: or perhaps a resolvable name allows non-normalized input, because that's technically resolvable
  • so this is a ResolveableName but what's the point in allowing non-normalized input for resolution, surely we should just say 'normalized segments only' because the use-case for non-normalized segments is more or less just spam/impersonation? exception is beautification, but we can still say the api requires normalized inputs and clients should beautify any outputs

so we only store WhateverName values for name records and only accept WhateverName values for resolution, so at all times in the resolution pathway names are WhateverNames.

And then should this constraint extend to the rest of the system? for example, should the resource api continue to operate over interpreted names? probably yes. but then omnigraph resolution of a Domain is conditional on the name being resolvable, so Domain.records must be nullable

Our protocol accelerated implementation of resolution should not be label hash aware either, to match behavior; we should ensure that no encoded-labelhash-aware functions are used in the resolution module.

we should also re-implement the dns encode/decode functions to only accept/produce this new branded type and to ensure that our usage of dns-decoded names is correct

also connect this to perhaps removing the Name and Label unbranded types in favor of just string with casts to asLiteral* when necessary? likely also want to brand NormalizedAddress and touch all indexer handlers to cast to our branded type

likewise want to brand LabelHash and EncodedLabelHash and Node as well

also likely introduce a branded type for a BeautifiedName see #1908 (comment)