A `ci` command alias auto-derived from workflow steps

As @djspiewak says:

basically ci isn't needed all that often, but when you do need it, you really need it
at least I've never worked on any long-lived project at any point in my career that didn't, at some point, need it

@rossabaker is this relevant at all e.g. when http4s does a release to patch a CVE? IIRC those are done manually, but is there a reason they can't/aren't done from CI?

Ross also had an idea in https://github.com/typelevel/sbt-typelevel/pull/65#issuecomment-1008422048 to make ci a task rather than a command.

I pointed out in https://github.com/typelevel/sbt-typelevel/pull/65#issuecomment-1008426170 that it's difficult/impossible to manipulate an opaque ci command and punted the issue. Early milestones of sbt-typelevel worked like this and it was annoying being unable to add a step to ci without redefining the entire command.

In any case, since the source-of-truth for CI is the workflow, and the plugin knows the workflow, we should be able to derive the ci command automatically. I've definitely thought about this but I'm not sure I have the sbt-fu to pull this off myself 😅

One thing that seems tricky to me is how this would interact with additional CI jobs added to the workflow e.g. as suggested in https://github.com/typelevel/sbt-typelevel/issues/93.

Review the proposed approach in the linked pull request #210 and the workflow-based CI discussion in this issue. Start by examining how sbt-typelevel currently defines the ci command and how additional CI jobs, such as those discussed in issue #93, should be handled. Done means the command is derived automatically without preventing additional CI steps from being added.