Rework Design Time Build to use .aar files directly.

[dellis1972]

So one of the big issues we have with design time builds is the shear amount of time they take.
This is principally because we have to discover and extract ALL the .aar/.zip files which we need before we can do a build.
This used to be because we embedded the data into the assemblies, but we ship these resources as .aar file these days.
So lets take advantage of that.

Rather then extracting to disk and then reading the files from disk, we instead read the .aar directly for a design time build. We extract the required data into memory which will allow us to generate the required R.txt file. Note that only a small amount of data is needed from the .aar , its mostly entry filenames and the contents of any .xml/.axml file which we find in the res folder. So this will cut down the amount of data we need.

We only use this for design time builds. The typical build is left as is , and if the on disk cache is available the design time build will use that instead of the .aars.

One of the things that was missing from our design time build tests was the SkipCompilerExecution MSbuild parameter. This is one of the important parameters which VS uses, it stops the Csc Task from creating an assembly on disk. This was the main speed issue we had in our unit tests, and adding this flag cut a second of our design time build times.

	Average Time
Before	2026.2504ms
This Commit	592.1775ms

[dellis1972]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dellis1972]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jonathanpeppers]

Looks good to me as-is. 👍

[jonathanpeppers]

This is probably not worth changing, but I wonder if it's better if this expression was first:

'@(LibraryResourceDirectories->Count())' == '0'

So, it would prevent MSBuild from batching/expanding the first part:

'%(LibraryProjectZip.Extension)' == '.aar'

It probably runs the ->Count() N times, but probably not slow enough to matter, though.

[jonpryor]

This change confuses me; before this change, the design-time build would fail; why? Are the reasons for that failure important? Or is it better to not have failures during a design-time build, as "real" errors will "surface" during a real build?

[dellis1972]

So before the DTB would fail because the library project .dll would not be found (cos it hand not been built yet).
In the new system we no longer need the project reference to be built we can still get the data we need as long as it has been restored because we read the .aar file directly.

As a result this now builds ok.

[jonpryor]

Context: https://developer.android.com/studio/projects/android-library#aar-contents

One of the big issues we have with design time builds is the shear
amount of time they take.  This is principally because we have to
discover and extract *all* the `.aar`/`.zip` files which we need
before we can do a build.

This used to be because we embedded the data into the assemblies, but
we ship these resources as `.aar` file these days.
Let's take advantage of that.

Rather then extracting to disk and then reading the files from disk,
we instead read the `.aar` directly for a design time build.
We extract the required data into memory which will allow us to
generate the required `R.txt` file.  Note that only a small amount of
data is needed from the `.aar`, its mostly entry filenames and the
contents of any `.xml`/`.axml` files which we find in the `res` folder.
This will cut down the amount of data we need.

We only use this for design time builds.

The typical build is left as-is, and if the on disk cache is available
the design time build will use that instead of the `.aar`s.

One of the things that was missing from our design time build tests
was the `SkipCompilerExecution` MSBuild parameter.  This is one of
the important parameters which VS uses, as it stops the `<Csc/>` Task
from creating an assembly on disk.  This was the main speed issue we
had in our unit tests, and adding this flag cut a second off of our
design time build times. 


|               |  Average Time |
| ------------- | ------------: |
|      ef9912af |   2026.2504ms |
|   This Commit |    592.1775ms |