## Summary
Fixes https://github.com/flutter/flutter/issues/139180, where `flutter create` could crash if the `java` binary the tool found cannot be run.

## Context

At startup, the tool searches for a Java installation[^1]. Unless the located installation is from [an Android Studio installation](https://github.com/flutter/flutter/blob/e1967ecabf014bf93d1731fde6a6547b06ca9c33/packages/flutter_tools/lib/src/android/android_studio.dart#L163), the tool does not verify that the binary is runnable. For more, see https://github.com/flutter/flutter/issues/139613, which tracks this inconsistency in behavior. 

This means that in the scenario where

1) the user does not have Android Studio installed or the java binary found within cannot be run **and**
2) the user has a) `flutter config --jdk-dir` set, b) `JAVA_HOME` set in their environment, **or** c) `java` on their system path **and**
3) the java binary we think we found during cannot be run (or `java --version` fails), **then**

the user running `flutter create` with Android enabled will hit a tool crash.

## Change

`Java.version` should return null if version checking fails for any reason. [This is documented behavior](https://github.com/flutter/flutter/blob/48f57621ade657b0c20ba53d513de4c3cd563abd/packages/flutter_tools/lib/src/android/java.dart#L136). Therefore, we'll update the implementation to first verify that the binary is runnable. If it isn't, it will return `null`.

[^1]: We find java by calling the static `Java.find`, see: https://github.com/flutter/flutter/blob/48187028c11ca8ca10e0179705d25553e1fe2c14/packages/flutter_tools/lib/src/context_runner.dart#L271
[^2]: This PR doesn't change this, as this would be too dangerous to cherry-pick into stable.

fixes flutter/flutter/issues/135402
Edge case that was reported by a user along with a test case specifically covering their output.

Fixes #135402
Add fallback logic for a different format of java version output and handle no patch versions. 
Add tests for new logic output to prevent regressions.

Per discord discussion, building an AAR out of a plugin project has not worked for years, so let's just disable the functionality. Context: https://github.com/flutter/flutter/issues/137564

Closes https://github.com/flutter/flutter/issues/106416.

This PR adds a new `flutter config` setting named `jdk-dir`. When set, the tool will use the JDK found at this location for all Java-dependent tool operations such as building Android apps via gradle and running Android SDK tools.

Fixes #124252, finishing work on the umbrella tracking issue, #126126.

Essentially, after this PR, no (non-test) code should be be referencing/invoking the java home or binary paths.

Relands #126086, which was reverted by #126569.

Reverts flutter/flutter#126086.

This PR changed the interfaces of some classes, namely `AndroidSdk`, and deleted a global.

These classes had custom overrides in g3 that were not updated with a g3fix, so this PR has broken tests. See https://b.corp.google.com/issues/281945232 (non-public link)

This is the first step in unifying Java-finding logic across the tool. If curious, see #126029 for an example of what all the changes will probably entail.

Moves java-related functionality like `AndroidSdk.findJavaHome` to a new class, `Java`.

See tracking issue https://github.com/flutter/flutter/issues/126126 for more.