[WIP] - Amazon Q Code Transform: Enforce valid JDK for user provided JAVA_HOME

[arangatang]

Problem

As part of the Code Transformation Process, users can provide a custom JAVA_HOME. Previously we only verified if the default JAVA_HOME was correctly detected and not this user provided JAVA_HOME.
This meant customers could pass an invalid JDK which could lead to the following problems:

1. Pass a path thats not even a JDK -> Causing build errors
2. Pass a path thats the wrong JDK version -> I.e. 17 and leveraging backwards compatibllity when build requires 8/11. This obfuscates certain issues and makes them only detectable during the first backend build which builds using the JDK 8 or 11.
3. Customers have to provide a custom JAVA_HOME multiple times upon retrying submission.

Secondary problem - Bugfix

Extracted to #4949

Solution

1. If JAVA_HOME recorded into state use that when verifying mavens detected JAVA version
2. Run validation also after JAVA_HOME is provided and ask customers to retry on failure.
3. Change all occurences in Q Code Transform of tabId to tabID - Extracted to Fix bug where messages to chat got lost. #4949

Screenshots

Screenshots for main problem

1. When running JDK 8 and user provides JDK 17 -> Ask customer to try again

2. When user retries with valid JDK, job continues

3. When user started a successfull job and provided a valid JDK version then subsequent jobs of same language version does not require users to provide JAVA_HOME again.

4. When user changes project to a JDK 11 project, we request a valid JDK version for that (even when JDK 8 version was successful for previous project)

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[arangatang]

Moved back to draft mode -> Discussed with team, i'll split this into two parts.

1. To fix the tabId issue - Fix bug where messages to chat got lost. #4949
2. Enforce valid JDK (this one)

[arangatang]

Force push due to rebase against master.

[arangatang]

Failing test seem to be flaky and is unrelated.

[arangatang]

Having some discussion internally if this is the way we want to go forward with this, so moving to draft mode to avoid accidental merges until this is decided.