Add "pins" as a grant segment

[jefferai]

Description

The ability to pin grants to a specific collection has been supported for a long time, but the syntax is confusing. It reuses ids (originally id) with the thinking that you are granting, e.g., read on host sets within the collection with id foobar. Or, from another standpoint, in foobar allow read on host sets. Look, it made sense at the time.

However, it means there are different potential meanings for what can go into ids, and that in turn makes it confusing to explain pins and can lead to subtle misunderstandings due to e.g. mismatched types.

This change allows pins to be used instead, which makes it very explicit what the intention is. Internally, for backwards compatibility, the behavior is very similar to pinning with ids with a few extra guardrails -- something we could consider changing in the future if we want, although we'd have to do it at the API level to ensure existing grants work -- but lets the user be more specific and expressive as to intent.

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.
• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.
• If applicable, I've documented the impact of any changes to security controls.
  Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.