Make federation a first-class citizen

[bufdev]

This PR makes federation a first-class citizen by effectively adding the concept of registry_hostname to all resources. registry_hostname is a rename of what we currently call remote within our codebases.

Motivation:

• There's work that I want to do to no longer send the full buf.yaml over the wire to the backend - we're defining the buf.yaml to not make up part of a Module, and once you do this, it becomes somewhat easy to deconstruct what you send over the wire. Even moreso, I'd argue this is desirable - the backend should not have to concern itself with buf.yamls, their layout, or their parsing, as they will not make up part of a Commit's digest.
• To do such deconstruction, you need some message that makes up what we call, ModulePin right now - a Commit and its associated Digest. However, both historically and likely soon-to-be in the future, we've allowed for federation, meaning that it's possible that some `Commits' may lie outside of the given BSR instance you are calling via the API.
• You therefore need a way to represent the registry of a Commit both in the request, and returned Commit objects.
• It was pointed out that a shortcoming of this API is that federation wasn't accounted for, and this is a use case we currently have for legacy reasons, regardless of what we want going forward (which may be federation as well).

The path to this PR:

• First, you realize you need to add a registry_hostname to Commit. Easy enough.
• Next, you realize that you need to qualify all IDs on the Commit as scoped to the BSR instance as denoted by registry_hostname. For example, module_id is now the ID of the Module on the BSR instance as denoted by registry_hostname.
• Inevitably, this means you need registry_hostnames the whole way down - Modules, Users, Organizations specifically.
• At this point, for consistency and because we're letting half of our resources account for federation, you realize you likely want registry_hostname on Tag, VCSCommit, Branch as well.

What this PR does:

• Adds registry_hostname to all resources.
• Clarifies in the comments that IDs are scoped to the given registry_hostname.
• Refactors .*Refs: .*FullNames are moved inside Refs as a nested message Name (this is likely a nice cleanup anyways, as we only use FullNames inside of Refs anyways at the API level). Since both id and name must be scoped to a registry_hostname, it is not desirable to repeat registry_hostname on both a theoretical id wrapper, and .*FullName, hence now defining .*FullName as a nested message that requires other data in the encapsulating message.
• Adds a CommitRef that will be used in the CommitService on CreateCommits in a future PR.
• Updates basically every comment to say that registry_hostnames need to match the BSR instance you are invoking for now. As this changes, we can relax these comments.

To be honest, I don't like it. It feels very messy. But I don't know if there's a better solution here, assuming we need to account for federation.

Let's discuss this on Monday @rodaine @jhump @Alfus @pkwarren @jchadwick-buf @saquibmian @doriable @mfridman and come to a conclusion.

[Alfus]

(nit: might "read" better to have Branch.Name instead of BranchRef.Name, which also makes me wonder about Branch.Ref)

[Alfus]

(which then also makes me wonder about using Branch.Name inside Branch, instead of flattening the fields into the main message) (oops, those are ids vs names huh?)

[bufdev]

You can't flatten them because it's in a oneof

[Alfus]

(I was suggesting unflattening the owner_id, etc, but now I realize those are ids not names)

[bufdev]

Closing as we've decided not to move forward with representing federation as-is in the new API, and will evaluate how and when we want to handle federation in the future, likely moving concerns client-side.