Bring in sbt-gh-actions

[armanbilge]

Closes #18.

I'm not dead set on this: I would just like to be able to iterate quickly for now so I can fix #61 and #60. I've also abandoned the tests for now, but those should be followed-up on.

This would become the largest and most complex plugin currently in this repo. Is it worth it?

IMO the relevant questions are:

1. Does it make sense to bring sbt-gh-actions under the Typelevel org? (imho yes)
2. Following (1), where should it live? And how should it publish itself? (still on the fence about this, but a monorepo does simplify things)
3. Besides changing the artifact groupid and package name, should we make any other scope-related changes?

Linking to:

• Don't bring in new plugins and outsource some of the existing  #20.

[rossabaker]

This functionality is one of the most important things in the ecosystem with a bus factor of one. Not mine to donate, but I'd love to see it graduate to Typelevel and hopefully take some pressure off @djspiewak.

[armanbilge]

I'd like to move forward with this, at least temporarily. Projects are already starting to adopt sbt-typelevel and some important (breaking) changes are currently blocked by this PR that I would like to get into v0.4.0-M4.

I had a Discord discussion earlier this week with @djspiewak and IIUC he is 👍 about sbt-gh-actions graduating to Typelevel but needs more time to think about whether or not it should specifically join in this monorepo.

For the majority of Typelevel projects some churn in sbt-gh-actions going into 0.4.0 final will not be a problem.

1. AFAIK there are no triangle dependencies with other plugins using sbt-gh-actions.
2. Builds are relying on autoimport rather than direct imports of sbt-gh-actions, so a change in package name would not be source-breaking.

[armanbilge]

Discussion can continue in #18.