Don't bring in new plugins and outsource some of the existing

[armanbilge]

Since I'm opening #17 and #18, it's only fair to consider the opposite argument. @ChristopherDavenport in particular encouraged that we delegate to his existing no-publish and mima plugins, and offered to donate them to typelevel org. sbt-tpolecat is another one we could outsource to instead of our own settings plugin.

My concerns with this are:

1. bus factor
2. try getting your head around how sbt-gh-actions is released by sbt-spiewak without a direct dependency :)

[rossabaker]

The more external repositories this integrates, the more liability if they break. Also the harder the next breaking SBT update is going to be. It's the classic monorepo vs. polyrepo debate. Separate repos win if the functionality needs a separate release cycle (no) or have clients that don't want sbt-typelevel (presently yes, but not if this is successful?).

This is also an argument against the most ambitious ideas of #16.

[armanbilge]

have clients that don't want sbt-typelevel (presently yes, but not if this is successful?)

It's cheating, but if development of sbt-gh-actions moved here, it could help with the success thing. I think the ci release plugin we have here is a natural next step:

1. a pure workflow generation plugin
2. a fill-in-the-blank plugin, i.e., you provide the CI and publish commands, plugin generates the workflows
3. a complete ci-release plugin, i.e. (2) with the publish step filled in, you just bring creds

(1) and (2) are the two parts of sbt-gh-actions today. I'd guess some of its users probably want (3) as well.

[armanbilge]

The current state of things is okay. Navigating sbt-tpolecat as an independent dependency is scary enough for now!