allow the users to anticipate the support of features in the targeted runner

As part of our user experience improvement to attract new Beam users, I would like to suggest something:

Today we only have the capability matrix to inform users about features support among runners. But, they might discover only when the pipeline runs, when they receive an exception, that a given feature is not supported by the targeted runner.
I would like to suggest to translate the capability matrix into the API with annotations for example, so that, while coding, the user could know that, for now, a given feature is not supported on the runner he targets.

=\> Eventually, the runner will need to decide if it can run a given pipeline so we need a validation process in the build process to inform the user if the pipeline is runable. Also it would require to specify the targeted runner. To avoid specifying it in the code (which is against Beam portability effort) we could specify it as a CLI parameter of the validation process.
=\> As a complement having a IDE plugin to give surface information to the user will be good also.

Imported from Jira [BEAM-5849](https://issues.apache.org/jira/browse/BEAM-5849). Original Jira may contain additional context.
Reported by: echauchot.

Start by reviewing the capability matrix and the proposed API annotations, then examine how a targeted runner could be supplied to a validation process through a CLI parameter. The issue also mentions an IDE plugin, so the scope needs narrowing. Done should mean unsupported runner features are identified before pipeline execution.

Written by the indexing model from the issue text.