I noticed a target running on an incremental build with only a XAML
code change:
    116 ms  _BuildLibraryImportsCache                  1 calls
This was using VS 2019 GA, just a blank Xamarin.Forms app.
Reviewing `<GetImportedLibraries/>` it had some general perf
improvements that could be done:
* It called `Directory.EnumerateFiles` three times...
* It used a bunch of LINQ where a `foreach` would do.
Additionally, I saw some improvements I could do at the MSBuild target
level:
    <Target Name="_BuildLibraryImportsCache"
            Inputs="$(MSBuildProjectFullPath);@(_ReferencePath);@(_ReferenceDependencyPaths);$(_AndroidBuildPropertiesCache);$(_AndroidLibraryProjectImportsCache)"
            Outputs="$(_AndroidLibraryImportsCache).stamp">
This target operates on the output of `_ResolveLibraryProjectImports`,
but it was re-running if *any* assembly changed?
I think the `Inputs` and `Outputs` would more appropriately be:
    Inputs="$(_AndroidLibraryProjectImportsCache)"
    Outputs="$(_AndroidStampDirectory)_BuildLibraryImportsCache.stamp"
This way, if `_ResolveLibraryProjectImports` runs and does work, it
writes to `$(_AndroidLibraryProjectImportsCache)`. We then only need
to run this task when that file changes.
I also updated this target so it follows our new convention for
placing stamp files in `$(_AndroidStampDirectory)`.
~~ Results ~~
An example of an initial build of the Xamarin.Forms project in this
repo:
    Before:
    299 ms  GetImportedLibraries                       1 calls
    After:
    172 ms  GetImportedLibraries                       1 calls
And then an incremental build, that is a XAML change:
    Before:
    109 ms  _BuildLibraryImportsCache                  1 calls
    After:
    n/a
The task is skipped now:
    _BuildLibraryImportsCache:
    Skipping target "_BuildLibraryImportsCache" because all output files are up-to-date with respect to the input files.
Overall, I would say there is a ~120ms improvement on initial build.
Incremental builds with XAML changes have a ~100ms improvement.