Concurrency and reusable workflows

[ingemaradahl]

This PR adds support for calling reusable workflows instead of listing steps within a workflow. Since there now exist a difference in the set of supported keys between a "standard" workflow job (which uses steps) and a calling workflow variant, the WorkflowJob trait is made into an sealed abstract class with two implementations: Steps and Use, with a slight difference in required and accepted arguments. To stay source compatible, the WorkflowJob.apply function is aliased to WorkflowJob.Steps to avoid build definitions using this plugin to change.

The concurrency keyword is disabled by default, I didn't really dare make a change which would require more or less all workflow to be regenerated (which I guess shouldn't be a problem as scala steward takes care of that), but I'm happy to change it to fall in line with what sbt-typelevel-github-actions does (or what is discussed in #79). The concurrency implementation is essentially a backport from the typelevel fork.

Resolves #79

[eed3si9n]

Calling an ordinary WorkflowJob with concrete steps as Steps I think is misleading what's specified here is a job, not the steps.

I suggesting keeping WorkflowJob as-is, and maybe name the abstract class as AbstractJob, and the new entity as WorkflowApply, since hopefully many people are familiar with calling function calls as apply.

[ingemaradahl]

Yeah I'm not super happy about the naming either. I chose this to mimic how individual steps are modeled in WorkflowStep.scala, where WorkflowStep is a sealed trait with the Run, Sbt, and Use implementations. Continuing that pattern, a WorkflowJob then would have two different implementations: one which is composed of steps, and then WorkflowApply.

Another alternative I just thought of is to keep WorkflowJob as a case class and instead introduce a sealed trait WorkflowAction which has the WorkflowApply and WorkflowSteps (naming TBD) implementations. An auxiliary factory apply function could be used to keep source compatibility.

If we introduce AbstractJob there's the potential of source incompatibility since some of the keys has to change. githubWorkflowAddedJobs becomes settingKey[Seq[AbstractJob]]. But maybe I'm being too cautious..

[eed3si9n]

Another alternative I just thought of is to keep WorkflowJob as a case class and instead introduce a sealed trait WorkflowAction which has the WorkflowApply and WorkflowSteps (naming TBD) implementations. An auxiliary factory apply function could be used to keep source compatibility.

I'm +1 with that direction.

[ingemaradahl]

@eed3si9n I've updated the PR to introduce said trait. Unfortunately it's not possible to use argument overloading in conjunction with default arguments on the apply function in WorkflowJob to suit both the "steps" and "apply" use cases. As before, the default behavior is to use "steps", to be source compatible. PTAL.