Feature parity between composite actions and javascript/docker actions

Problem

Composite actions cannot interoperate with javascript actions and docker actions that use non-declarative outputs. From the documentation of javascript and docker actions:

If you don't declare an output in your action metadata file, you can still set outputs and use them in a workflow. For more information on setting outputs in an action, see "Workflow commands for GitHub Actions."

However, this feature is not available to composite actions. That means if a composite action includes an action that exports non-declared outputs, the composite action cannot export those outputs.

The Composite Actions ADR makes a compelling argument for the choice to not expose all outputs from all steps; namely

The reason why we are [not exporting step outputs] is that we don't want to require the workflow author to know the internal workings of the composite action.

This makes sense and we can stay true to this principle while also maintaining feature parity with javascript/docker actions.

Proposal

A natural way to implement this capability would be to allow a developer to choose a step, declared in a parameter called stepOutputs, that exposes all outputs of a given step. As an example, what previously would be written as this:

outputs:
  random-number:
	description: "Random number"
	value: ${{ steps.random-number-generator.outputs.random-id }}
runs:
  using: "composite"
  steps:
	- id: random-number-generator
  	run: echo "::set-output name=random-id::$(echo $RANDOM)"
  	shell: bash

, could now be written as this:

stepOutputs: gather-outputs
runs:
  using: "composite"
  steps:
	- id: random-number-generator
  	run: echo "::set-output name=random-id::$(echo $RANDOM)"
  	shell: bash
	- id: gather-outputs
  	run: echo "::set-output name=random-number::${{ steps.random-number-generator.outputs.random-id }}"
  	shell: bash

This gives us two properties:

1. We don't expose the internals of the composite action (random-id is not exported).
2. We can expose a dynamic set of outputs

Furthermore, it is a literal extension of the guiding principles of composite actions:

A composite action is treated as one individual job step (this is known as encapsulation).

Start with the Composite Actions ADR and the metadata documentation linked in the issue, then trace how composite action outputs are currently defined and exposed in the runner. Done means a composite action can select a step whose dynamic outputs are exposed without exporting the composite action's internal step outputs.