[Xamarin.Android.Build.Tasks] don't use so many temp files

[jonathanpeppers]

In many places throughout the Xamarin.Android build, we have a pattern
of:

• Generate a temp file.
• Use MonoAndroidHelper.CopyIfChanged to put the file in the
  destination. This reads both files, doing a hash comparison before
  deciding to write or not.
• Delete the temp file.

Sometimes the temp file is actually in %TEMP%, but other times we
append .new to the destination file. The case of .new can collide
if two builds are running at once (example caused by a known VS for
Mac issue).

Thinking about this, in cases with small files, we can make a simple
optimization:

• Generate the file in-memory.
• Use a new MonoAndroidHelper.CopyStreamIfChanged method`.

This has several benefits:

• We never write a file to disk when there are no changes.
• We don't have to remember to delete the file.
• The code, in general, is slightly simpler.

The only place we likely shouldn't use this new pattern, would be if
the file was huge.

Changes

I added new APIs for:

• Files.HasStreamChanged - to compare a Stream in memory
• Files.HasBytesChanged - to compare a byte[] in memory
• Files.CopyIfStreamChanged
• Files.CopyIfStringChanged - some cases we have a string
• Files.CopyIfBytesChanged - this supports string
• MonoAndroidHelper.CopyIfStreamChanged
• MonoAndroidHelper.CopyIfStringChanged
• MonoAndroidHelper.CopyIfBytesChanged

I changed the following MSBuild tasks, mostly to test out the new
behavior:

• GenerateResourceDesigner was using a .new file.
• GenerateJavaStubs was using temp files in many places. I was able
  to fix up all the places except where Generator.CreateJavaSources
  writes Java code to an output directory.

I made other general refactoring in GenerateJavaStubs:

• The top-level temp directory we still use, should be deleted in a
  try-finally!
• Since we don't have to worry about deleting a temp_map_file, we
  can return earlier if Generator.CreateJavaSources fails.
• A GetResource<T> method, cleans up the places reading from
  EmbeddedResource files. I also changed it up to properly Dispose
  things.
• A save anonymous method/delegate should just be a SaveResource
  regular method.
• A few places were calling Path.GetFullPath unecessarily. Since
  this method accesses the file system, we should skip it unless the
  full path is actually needed.

I also added some tests for the new APIs in MonoAndroidHelper.

Results

I did three test runs, because I was getting varying times for
GenerateJavaStubs. This is the Xamarin.Forms integration project in
this repo:

Before (Clean Build):
1. 1587 ms  GenerateJavaStubs                          1 calls
2. 1503 ms  GenerateJavaStubs                          1 calls
3. 1553 ms  GenerateJavaStubs                          1 calls

After (Clean Build):
1. 1424 ms  GenerateJavaStubs                          1 calls
2. 1461 ms  GenerateJavaStubs                          1 calls
3. 1529 ms  GenerateJavaStubs                          1 calls

Before (Incremental):
1. 1775 ms  GenerateJavaStubs                          1 calls
2. 1490 ms  GenerateJavaStubs                          1 calls
3. 1664 ms  GenerateJavaStubs                          1 calls

After (Incremental):
1. 1443 ms  GenerateJavaStubs                          1 calls
2. 1480 ms  GenerateJavaStubs                          1 calls
3. 1589 ms  GenerateJavaStubs                          1 calls

GenerateJavaStubs is now consistently faster, but it's hard to tell
how much. I feel it is likely 100ms better. I have an SSD, so I'd
expect developers with an HDD to see even bigger improvments.

I could not see a difference in GenerateResourceDesigner, likely
since it wrote only a single temp file.

Next steps would be to make changes in Java.Interop so we could get
the same CopyIfStreamChanged behavior for all generated Java
files. There are likely other MSBuild tasks to change as well.

[jonathanpeppers]

We can wait until after branching to merge this.

[jonathanpeppers]

Actually looks like I could use a TextWriter overload here: https://github.com/xamarin/xamarin-android/blob/24517ef0095dbcb8bdd2e88edb41227215c96b37/src/Xamarin.Android.Build.Tasks/Generator/Generator.cs#L49

So I could remove all the temp files in GenerateJavaStubs, without a Java.Interop change... I'll try it.

[jonathanpeppers]

So I could remove all the temp files in GenerateJavaStubs, without a Java.Interop change... I'll try it.

Nope: d510ca0

Will need to add one public method here in Java.Interop, something like:

public string GetDestinationPath (string outputPath)
{
	string path = outputPath;
	foreach (string dir in package.Split ('.'))
		path = Path.Combine (path, dir);

	if (!Directory.Exists (path))
		Directory.CreateDirectory (path);

	path = Path.Combine (path, name + ".java");
	return path;
}

package is private to JavaCallableWrapperGenerator.

So we can take this PR as a first step, and do more later.