Is your feature request related to a problem? Please describe.

Sometimes it is useful to be able to upgrade to an in-development version of a library before that branch of the library has an official release. Examples:

• A fix/feature has been merged to /main but the library maintainers haven't cut a release with it yet.
• You want to test the downstream affects of a library change before committing it to a release.
• You want downstream library support to be established before a release is advertised.
  • For example the Unison Cloud backend depends on types and tests in the Cloud client library, so we need to update the cloud client for new features. But we don't want to officially release features in the Cloud client library until the backend supports them.

Describe the solution you'd like

• A documented best practice for depending on a version of a library that only exists in a branch (not a release). Preferably that will work even if the branch is local and hasn't been pushed to Share.
• Possibly/ideally something that doesn't clutter the dependent library with the entire history of the dependency library. This point can potentially be ignored if there is evidence that it isn't an issue. But cloning projects can currently take dozens of minutes, and I don't want that time to go up if this flow is used.
• Something that plays nicely with the upgrade command (and its friends like upgrade.commit).

Additional context

I've asked about this a few times like here, here, and during a Nimbus pairing session, but I've never really gotten an answer.