[tests] Check for emulator issues and error early

[jonpryor]

The Android emulator is a "wonderful" beast. Case in point:
PR Build #1074, which hung during emulator startup, for
5 hours:

09:13:49 Hax is enabled
09:13:49 Hax ram_size 0x0
09:13:49 HAX is working and emulator runs in fast virt mode.
...
09:13:56 		adb I 06-21 09:13:56 47148 21294922 adb_io.cpp:75] readx: fd=3 wanted=4
...
# 5.5 hours later...
14:47:17 		Tool /Users/builder/android-toolchain/sdk/platform-tools/adb execution finished.

It "finished" because I manually killed the Job, as it had take over
6 hours, cumulative, to do nothing.

(Arguably we shouldn't have a 10 hour timeout on Jenkins jobs, but
Mono bumps can take upwards of 6 hours to build, so a 6 hour time
isn't necessarily unusual...)

This also isn't our first attempt at improving emulator reliability.
See also commits c089267, bc6440b, 3fa9e9e, b54f8cd, 3b893cd,
7450efc, and 6358a64. (Is that enough? Likely not. Is that all of
them? Probably not.)

Take yet another stab at improving things: in this case, improving
error checking, so that when an error occurs we can fail early, as
opposed to waiting for hours on end for a Jenkins timeout to occur
or for me to get annoyed at general Jenkins build slowness enough to
track down the hung job and manually kill it...

Update the emulator process launch so that we have event handlers
for stdout and stderr messages, so that we can look for currently
known error conditions, which fall into two categories:

1. HAXM needs reinstallation, or
2. Another VM is in use.

HAXM appears to need reinstallation when no memory is allocated:

Hax ram_size 0x0

I don't know why HAXM would require re-installation in these
circumstances, but that generally appears to fix the problem.

When another VM is in use, e.g. when I'm running a Veertu VM on macOS,
emulator also fails to launch, writing the following to stderr:

Failed to sync vcpu reg
Failed to sync HAX vcpu contextInternal error: Initial hax sync failed

If either of these conditions occur, the <StartAndroidEmulator/>
task should fail, with a (hopefully) relevant error message.

With these changes in place, remove the <Sleep/> task invocations
from the AcquireAndroidTarget target, as the new 20 second timeout
in <StartAndroidEmulator/> removes the need for the first Sleep, and
the 2nd sleep doesn't appear to do any good.

Followup to c089267!

in case the added sleep doesn't help, we might at least get some
more useful information

We do get more information. It's not entirely useful: adb is
waiting for adbd to provide it information, and that information
never arrives:

adb I 06-21 09:13:56 47148 21294922 adb_io.cpp:75] readx: fd=3 wanted=4

...and there it waits, seemingly forever, until Job timeout or Job
death occurs.

[radekdoulik]

The build took very long time. It looks like Azure related though, so hopefully next build will be OK.

03:30:03 	 0 Warning(s)
03:30:03 	 0 Error(s)
03:30:03 
03:30:03 Time Elapsed 00:01:02.7685530
03:30:03 Upload artifacts to Microsoft Azure Blob storage is waiting for a checkpoint on xamarin-android-pr-builder #1078
07:46:06 MicrosoftAzureStorage - Uploading files to Microsoft Azure```