[Epic] Improve test matrix to include all supported spring versions about spring-cloud-azure-tools HOT 1 OPEN

1. The structure of (spring-cloud-azure-supported-spring.json) (temporary name)
   tools repo project produce a json file:

[
  {
	"current":  "true"  (unique in the list, should equal spring cloud azure source code)
	"spring-boot-version": "2.6.8"
	"spring-cloud-version": "2021.0.2"
	"releaseStatus": "SNAPSHOT",
	"snapshot": "true"
	"supportStatus": "endoflife | supported | todo" (our support information need manual maintenance)
										      (new entry is default to todo, and we can use another pipeline to test the supportability)
										      (spring metadata removes one version, we can try to create an issue to suggest/query whether we should mark the version to EoL(end of life))
  },
  {
	"current":  "true" 
	"spring-boot-version": "2.6.7"
	"spring-cloud-version": "2021.0.1"
	"releaseStatus": "SNAPSHOT",
	"snapshot": "true"
	"supportStatus": "endoflife | supported | todo"
  }
]

2. What's the JSON file should consist of?
   [history Spring project metadata] = [spring cloud azure json].

3. What will happen if a version is EoL but still returned from the Spring metadata?
   For example, 2.3.13 is end of life; we need to set its EOL manually.

4. If the tools output a JSON file, should the sdk pull the file, or should the tools create a PR to the sdk repo?
   tools: output a JSON

   • sdk pipeline pulls JSON from tools

     - It's easy, it only requires an HTTP call
     - this need the tools repo to be a public repo
     

   • tools push JSON to the sdk repo,

     - To create a PR to the SDK repo
     - The JSON represents our supportability
     - Spring Cloud Azure's supportability is traceable through PR
     - It's how azure-core Jackson does
     

5. If we detect a change in the value of current: true, what should we do?
   we need to create a PR to the sdk repo:

   • upgrade version_txt
   • upgrade versions

from spring-cloud-azure-tools.