Automation of VEX generation

We should think about workflows and tooling around VEX generation for our artifacts. VEX( Vulnerability Exchange) should provide information about known security issues in Airflow dependencies and whether they are affecting Airflow or not. They can be based on SBOM information that we are publishing,

There are however few dragons ahead.

* VEX files will be ever-growing and the more time will pass for old versions, the more vulnerabilities in dependencies will be revealed.

* Likely we do not want to make it "maintained" by maintainers, but it should be open to our users to submit the information

* We don't want our users not to expect us to always analyse all VEX information for historical versions. This would be completely overwhelming for us if we have to "assess" vulnerabilities for all our dependencies - we have 700 dependencies and that translates to 100s of vulnerabilities for a 1-2 year old release. We should only publish VEX for the LAST version of Airflow/Images.

* In some cases we can easily assess if 3rd-party vulnerability affects us or not - in this case we can authoritatively say that and create an appropriate issue (in public or private) that will capture the state and will allow us to get ourselves assigned and closed when the issue is fixed.

* In some cases when it is not clear and it would take a lot of time, we should allow for "we are likely not affected, but we are not sure and we welcome contributions from our users to either help us to analyse the issue by:
* auditing
* paying researchers
* submitting a reproducible scenario following our security policy
* contributing to issue we open that describes the blocker that prevents us from adapting to newer versions or fix the vulnerability and how others can help

* The VEX should be also turned into "Human readable" page - so that we can direct anyone who asks to read the information

* We should have a mechanism to keep track of status (with links to issues) and to refresh such VEX information proactively (for example based on automated tools such as `scout` that will help us to proactively see issues reported in 3rd-party dependencies in our Image: https://github.com/apache/airflow/issues/34243

Start by reading issue #34243, the repository's security policy, and the requirements in this issue for SBOM-based VEX, current-version scope, user contributions, issue links, and automated refreshes. Define the workflow and tooling needed to generate VEX and a human-readable page; done means the ownership, status tracking, refresh process, and contribution path are explicitly specified.

Written by the indexing model from the issue text.