Context: dotnet/android@b002dc3
Context: dotnet/maui#14531

Once Upon A Time™ (about a year ago), if we got a java failure, the cause of the error could be unscrutable:

error : java.lang.RuntimeException: com.android.tools.r8.CompilationFailedException:
Compilation failed to complete, origin: obj/Debug/net7.0-android/lp/59/jl/classes.jar :
android/support/v4/app/INotificationSideChannel$Stub.class

Why did it fail? To find out we'd invariably have to ask for a diagnostic build log, because only the diagnostic build log contained the full output of r8.jar, which would contain the "root" error:

Type android.support.v4.app.INotificationSideChannel$Stub is defined multiple times:

java invocations are not the only place this "inscrutable error messaging" scenario comes up. Enter XA3006 (via dotnet/maui#14531):

error XA3006: Could not compile native assembly file: environment.arm64-v8a.ll
error XA3006: 
error XA3006: 

How helpful! How actionable!

Yet again, we need to ask for diagnostic build log information (which became a problem on its own right…).

Enough!

Update AndroidToolTask so that it provides output logging infrastructure, a'la dotnet/android@b002dc38, such that all tool output is always captured (as well as logged via LogDebugMessage()), and when an error occurs, all captured output is part of the error message.

We can then update JavaToolTask and other subclasses to use this common infrastructure.