PR process revamp

[aryairani]

UPDATE: latest design is here

---

No longer relevant -

There's some initial work in #2105, but we went down a rabbit hole looking at how we might embed PR bundles into github markdown, and never picked it back up again.

[pchiusano]

The last idea on this that I recall is that PRs are encoded as namespaces with two subnamespaces, base, and head. An anonymous namespace is created for this when pr.create is made.

.> pr.create my_new_feature29 current_trunk

<maybe show diff here of what merged result will be>

Created PR bundle #a3048b120 and pushed to https://github.com/pchiusano/unisoncode.
Use:
  
    pr.load https://github.com/unisonweb/pchiusano:#a3048b120

To load this PR locally.

Then pr.load loads that namespace and can intelligently provide a list of targets for the merge, based on things which have the same base as a common ancestor.

So no weird bundle format needed, and this takes advantage of the efficient syncing of namespaces that already exists.

[pchiusano]

Phase 1 of this should just be a timeboxed design jam / prototyping / implementation sketch of 2 days to decide on 1 or more possible approaches and better estimate level of effort.

[aryairani]

Ok, I like this idea.

[aryairani]

I closed #2105, but we might want to copy from its InputPatterns.hs.

[aryairani]

We(Simon and I)'re thinking that we'll just be using normal branch comparison tools to inspect and compare contributor branches. We'll sort out how to compare against the PR base vs how to compare against the current main on share. Maybe this diff would only be on Share and not something we try to do in UCM; idk tbd.