Various issues exhibited when local and remote base branch names are not the same

Due to having a single repo with many different forks of LLVM checked out into various worktrees, my local branch names for things like "main" are often prefixed; e.g. my local branch that tracks llvm/llvm-project is upstream-main. For most operations this seems to work fine, I could gh stack init --base upstream-main and create my stack locally. However, when it came time to submit, I got the following:

```
% gh stack submit --auto --open
Checking stack state...
? Multiple remotes found. Which remote should be used? upstream
? Save "upstream" as the default remote for all gh stack operations? No
Pushing to upstream...
⚠ failed to create PR for users/jrtc27/lld-test-aarch64-ifunc-bti: creating PR: GraphQL: Head sha can't be blank, Base sha can't be blank, No commits between upstream-main and users/jrtc27/lld-test-aarch64-ifunc-bti, Base ref must be a branch (createPullRequest)
✓ Created PR #210611 for users/jrtc27/lld-test-ppc32-ifunc-nonpreemptible
✓ Created PR #210612 for users/jrtc27/lld-replaceWithDefined-skip-copy
✓ Created PR #210613 for users/jrtc27/lld-handleNonPreemptibleIfunc-skip-pointless-alias
✓ Created PR #210614 for users/jrtc27/lld-handleNonPreemptibleIfunc-no-copy-constructor
✓ Created PR #210615 for users/jrtc27/lld-Symbol-remove-copy-constructor
✓ Created PR #210616 for users/jrtc27/lld-handleNonPreemptibleIfunc-addSyntheticLocal
✓ Stack created on GitHub with 6 PRs (stack #210617)
✓ Pushed and synced 7 branches
```

There are three issues here:

1. gh-stack should have been able to figure out that, given upstream-main is the base branch tracking refs/remotes/upstream/main, upstream is the sensible remote to automatically use (but that's a minor nice-to-have)
2. gh-stack should be querying the upstream branch for the base branch and using that as the branch name (minus the refs/remotes prefix), not the local branch (presumably only falling back to the local branch name if there is no upstream branch, if that's a sensible thing to do)
3. If creating a PR fails, gh-stack should stop before it makes things worse, as fixing this up manually is a bit of a pain (you have to create the missing PR, unstack the existing stack and only then can you re-stack the entire thing, since gh stack link currently doesn't let you add to the front of the stack, presumably due to the API being a bit deficient...)

Start with the gh stack submit --auto --open flow and trace how local branches, upstream tracking refs, and remotes are selected before pull request creation. Reproduce the reported upstream-main case and verify the base branch sent to GitHub, remote selection, and behavior after a PR creation failure. Done means all three reported problems are addressed without leaving a partially submitted stack.

Vom Indexierungsmodell aus dem Issue-Text verfasst.