Fixes #376

Continuing the description there:

I've added GitHubStage which extends Stage, adding the properties of AddGitHubStageOptions to StageProps. Stage ignores them, and they quickly get lost in the conversion to a StageDeployment, so we also need to catch that conversion.

I made a subclass of Wave called GitHubWave since n both wave.addStage() and pipeline.addStage() (which is defined in pipeline_base as this.addWave(stage.stageName).addStage(stage, options)) the the Stage object itself is tossed.

GitHubWave takes the parent GitHubWorkflow as an additional parameter, and GitHubWorkflow.addWave() calls new GitHubWave(id, this, options). GitHubWave only overrides addStage() to call parent.addingStageFromWave() with the unaltered Stage in addition to super.addStage(stage, options).

I have also added GitHubWave.addStageWithGitHubOptions() to match GitHubWorkflow.addStageWithGitHubOptions() as well as GitHubWorkflow.addGitHubWave(), but those can likely go away.

The trick is the JSII rules preventing "overriding or implementing a member using covariant parameter or return types" - which means we cannot make addStage() or addWave() take different parameters or have a different return type. However, we can accept and return classes that are descendants of those types, and use instanceof to catch them and get the additional information and functionality that they carry. So, pipeline.addStage() can accept a GitHubStage as a Stage, and pipeline.addWave() can return a Wave that's actually a GitHubWave. This allows us to maintain the same call structure but pass more information when we want.

How well that works in the other languages is TBD. If the JSII rules are sufficient, then it should work. In the least, JSII compiles it. 😄