Consider modifying the working with branches demo

In our working with branches demo, we pre-create two branches for parts 3 and 4
https://github.com/AlexsLemonade/2023-chop-training/blob/f28a5e98a6ece0bf5ff07378150874646ddf8f51/instructor-notes/working-with-branches.md?plain=1#L22-L25

The original idea here was to save time, but I don't think this was a particularly important time-saver! Moreover, it makes the examples less realistic. Below I'm proposing updates for how we might modify this live demo in the future. I expect some discussion over this, but I don't think we need to rush to implement these changes until we know if/when we'll be running this workshop again. This issue is mostly to record my immediate thoughts after doing this demo live!

### In part 3 of the demo:
- we accidentally work in the wrong branch
- we save the work with `git stash`
- then we switch into the correct pre-created branch and `stash apply`

#### why this merits revisiting

Stashing is great for modified files, but is sort of contrived for _brand new files_ as presented here - we could have just switched into a new branch and the changes would "just be there".

#### proposed update
- actually make the branch when we need to use it!
- If we want to keep `git stash`:
- rather than working on an entirely new script for this part, we might want to modify one of the scripts from part 1 or 2, which would mean using a different issue
- Or, we could actually commit in the wrong branch and `git cherry-pick` (see next part of issue where I suggest maybe removing cherry pick from part 4!)

### In part 4, of the demo:
(edited for syntax)
- we accidentally work in the `main` branch
- branch protection saves us from pushing
- we then go back to one of those pre-created branches and cherry pick

#### why this merits revisiting

The only reason we actually cherry pick is _because_ the branch was pre-created! If we created it after making commits incorrectly in main, then we would not need to cherry-pick at all - the commits would just "be there", and we'd only have to go back and `git reset --hard` the `main` branch to clean up.

#### proposed update
- commit in main as before
- make the branch when pushing fails, which can just be pushed right away
- then, just go back and reset main without any need for cherry-picking

### but!!

We would still like to teach `git stash` somehow!
Perhaps it would be good to teach this alongside "taming your PR diff", which is effectively the "stacking" demo. A better motivation for `git stash` is WIP that you want to save and come back to later, which would be a scenario where you got excited about working on code that is beyond the scope of a given issue.

Start with instructor-notes/working-with-branches.md, especially the linked lines and the descriptions of parts 3 and 4. Review the proposed branch, stash, cherry-pick, and reset flow before deciding on the workshop design. Done means the demo reflects an agreed workflow while still providing a suitable way to teach git stash.

Written by the indexing model from the issue text.