Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=61073
Context: a296784

When we added the new `classes.zip` functionality, there was one oddity
present. On the first build, everything appears to be normal. On the
second build, `classes.zip` appeared to contain itself inside itself???

To make things even stranger, I wrote a unit test that contains a
`Java.Lang.Object` subclass in which its type and namespace names change
on each write. This worked fine on macOS, even with the oddity of
`classes.zip` continually zipping itself inside itself... The new java
sources would appear at the bottom of the list within the zip file.

Everything broke down when I tried my unit test on Windows, the case of
`classes.zip` trying to compress itself inside itself was silently
failing. It was not processing any further files after the failing zip
entry, and so *in theory* this situation would cause many Java stubs to
be missing from the zip.

Solution? Let's just put `classes.zip` up one directory.

So instead of:
```
obj/Debug/android/bin/classes/classes.zip
```
Move it to:
```
obj/Debug/android/bin/classes.zip
```

This prevents the `classes` directory from containing `classes.zip`, and
our strange case of `classes.zip` inception.

Merry Christmas! I'm going to go play Skylanders now.

Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=61073
Context: a296784

When we added the new `classes.zip` functionality, there was one oddity
present. On the first build, everything appears to be normal. On the
second build, `classes.zip` appeared to contain itself inside itself???

To make things even stranger, I wrote a unit test that contains a
`Java.Lang.Object` subclass in which its type and namespace names change
on each write. This worked fine on macOS, even with the oddity of
`classes.zip` continually zipping itself inside itself... The new java
sources would appear at the bottom of the list within the zip file.

Everything broke down when I tried my unit test on Windows, the case of
`classes.zip` trying to compress itself inside itself was silently
failing. It was not processing any further files after the failing zip
entry, and so *in theory* this situation would cause many Java stubs to
be missing from the zip.

Solution? Let's just put `classes.zip` up one directory.

So instead of:
```
obj/Debug/android/bin/classes/classes.zip
```
Move it to:
```
obj/Debug/android/bin/classes.zip
```

This prevents the `classes` directory from containing `classes.zip`, and
our strange case of `classes.zip` inception.

Merry Christmas! I'm going to go play Skylanders now.

Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=61073
Context: a296784

When we added the new `classes.zip` functionality, there was one oddity
present. On the first build, everything appears to be normal. On the
second build, `classes.zip` appeared to contain itself inside itself???

To make things even stranger, I wrote a unit test that contains a
`Java.Lang.Object` subclass in which its type and namespace names change
on each write. This worked fine on macOS, even with the oddity of
`classes.zip` continually zipping itself inside itself... The new java
sources would appear at the bottom of the list within the zip file.

Everything broke down when I tried my unit test on Windows, the case of
`classes.zip` trying to compress itself inside itself was silently
failing. It was not processing any further files after the failing zip
entry, and so *in theory* this situation would cause many Java stubs to
be missing from the zip.

Solution? Let's just put `classes.zip` up one directory.

So instead of:
```
obj/Debug/android/bin/classes/classes.zip
```
Move it to:
```
obj/Debug/android/bin/classes.zip
```

This prevents the `classes` directory from containing `classes.zip`, and
our strange case of `classes.zip` inception.

Merry Christmas! I'm going to go play Skylanders now.

Context: #5331

Changes: xamarin/monodroid@0eef889...27736a7

  * xamarin/monodroid@27736a7ff: [tools/msbuild] Fix App Bundle deployment (#1142)
  * xamarin/monodroid@f38dbc7ab: [tools/msbuild] use @(_AndroidMSBuildAllProjects) (#1140)
  * xamarin/monodroid@cfa21d57b: [tools/msbuild] Fix some issues with FastDev (#1139)
  * xamarin/monodroid@3ba648386: [tools/msbuild] Add missing parameter to BuildAppBundle. (#1138)
  * xamarin/monodroid@5bb29971b: [tools/msbuild] Add Multi User Support for Debugging. (#1135)
  * xamarin/monodroid@156abf47c: [tools/msbuild] default $(_AndroidAllowDeltaInstall) to false (#1137)
  * xamarin/monodroid@fbc961218: [build] Pass EnableCompression to BuildApk (#1094)

Add support for running multi-user unit tests on device.  It makes
use of various adb commands to create test users and remove them.

Create a guest user with name `{name}`:

	adb shell pm create-user --guest {name}

Remove a guest user with the specified user id `{userId}`:

	adb shell pm remove-user --guest {userId}

Note that user creation takes a "name", while deletion takes an id.
To obtain the mapping, use:

	$ adb shell pm list users
	Users:
		UserInfo{0:Owner:c13} running
		UserInfo{10:guest1:414}

The userId is the number *between* the `{` and the `:` and user name.
The userId for `Owner` is 0, while the userId for `guest1` is 10.

We can then use a `Regex` to pull out the required `userId` for a
specific user.

To switch a device to use user `{userId}`:

	adb shell am switch-user {userId}

Emulators seem to create the main user with the name "Owner", so that
should be the default name we use for the main user.  In the unit
tests if we cannot find a user named "Owner" when looking for "Owner"
we will default to a `userId` of `0`.  User ID 0 always means the
default user.  This is to handle the case where we are testing locally
on devices where the main user is not called "Owner".