feat: add session name template support

[ethanpailes]

Issue Link

#345

AI Policy Ack

Please ack that you have read the AI Policy
and explain your use of AI to generate this PR.

This PR was:

• mostly or completely vibe coded
• mostly or completely meat coded
• bit of both

I vibed the tests, but meat coded all the application code.

Description

This patch adds support for session name templates so that you can switch multiple shpool sessions all at once.

In some sense this is a super-set of the 'shpool switch' FR. I did lay some groundwork for implementing support for that in this change, though I'm starting to wonder if templates are good enough on their own. The only extra thing that switch would bring is the ability to switch sessions you don't pre-declare as switchable with a dedicated variable up front.

One thing worth bikeshedding: At first I was thinking '${var}' for
the substitution syntax, then realized that would be weird about
nesting when it comes to shells, so I switched to '#{var}' syntax,
but then I realized that's the comment char in shells, and wound up
on '@{var}'. I'm open to other symbol/syntax ideas.

[ethanpailes]

@GeoffChurch this is the session name template thing we were talking about in case you want to review or join in the syntax bikeshedding.

[GeoffChurch]

@{var} is nice, but would just {var} w/o the prefix or Angular-style {{var}} work too?

[ethanpailes]

Yeah that would work and I think it would look nice. I don't really have intuition pushing in either direction between @{var} and {var}. Using a sigil seems somewhat nice because it is signposting that something abnormal is going on, but on the other hand pure braces are cleaner looking.

[GeoffChurch]

That makes sense. Support for {var} automatically implies support for @{var} and all other possible sigils, which might actually be an argument against raw {var} since guarding it with a particular sigil leaves you free to choose other semantics for other sigils down the road.

[ethanpailes]

I don't see how {var} implies support for @{var} they are semantically identical, they just have a different syntax. If you were to write @{var} in a template that uses {var} syntax it would result in @val instead of val so they are different.

That's a good point about reuse, though since sigils are not reserved any new sigil would technically be a breaking change. I suppose we could take this opportunity to make it a hard error to include a set of other sigils for forwards compatibility.

I'm not really sure what other sigils we would ever want though. The only extension to this scheme I can think of would be introducing some sort of string munging dsl that would allow people to compute things in terms of variables. I can't really think of any reasonable usecases for that for session name templates, but I was planning to follow this up by added a templated --start-cmd option so you can configure a hook so that sessions can configure themselves on first startup. Even then, I'm not really sure why you would need to munge the string in the template instead of just manipulating it in your startup command using shell tools.

[GeoffChurch]

I don't see how {var} implies support for @{var} they are semantically identical, they just have a different syntax. If you were to write @{var} in a template that uses {var} syntax it would result in @val instead of val so they are different.

I just meant that it would still do the replacement.

I also can't think of any compelling use cases for different sigils. Especially since with a single sigil / simple string replacement you can already e.g. set up an external process to call shpool var set upon changes to the current git branch or environment variables.

[ethanpailes]

Ok, I'll strip out the @ entirely and just do {var} syntax. It's cleaner and since neither one of us can think of a usecase for other sigils it seems better.