`fcli * action`: Add support for pipeline-style actions

[rsenden]

Current action framework is focused on retrieving, processing and outputting data. Ideally, we should also support pipeline-style actions, for example allowing an action to run the following steps:

1. Set up fcli SC-SAST & SSC sessions
2. Run 'scancentral package' command to package source code
3. Run fcli sc-sast scan start command to submit scan request
4. Optionally run fcli sc-sast scan wait-for command to wait for scan completion
5. Optionally run fcli ssc action run *-sast-report to export scan results
6. Optionally run fcli ssc action check-policy to evaluate security policy outcome
7. Terminate SC-SAST & SSC sessions

We would have a similar sast-scan action in the FoD module, or maybe even a non-product-specific action that automatically selects either FoD or SSC/SC-SAST scan based on input parameters/environment variables, similar to the sast-scan.sh script in the fortify-ci-tools image.

This would be very beneficial for our CI/CD integrations like GitHub Action and GitLab templates, as we don't need to implement the same steps in every individual integration, but rather just have those integrations invoke these sast-scan actions. Also, we could provide an easy option to have users point to a custom sast-scan action that performs extra customer-specific activities, sets some customer-specific defaults (like SSC URL), or uses a custom check-policy action.

In order to implement this, we'd need to solve various limitations in the current actions framework:

1. Improve session management for actions (#547)
2. Ability to invoke scancentral package and potentially other commands (#548)
3. Current framework only allows for collecting data from fcli commands, and doesn't allow for running non-data commands like invoking other actions (required for running the *-sast-report and check-policy actions). We'd need to add support for running arbitrary fcli commands without collecting their output, but rather output command output to console (see next point).
4. Ability to provide immediate command output for every command being run, without interfering with progress messages (#538)

Once implemented, this will fix #1