[Xamarin.Android.Build.Tasks] Improve error text

[brendanzagaeski]

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=43245

I wouldn't be surprised if this download mechanism gets redesigned at
some point in the future. That could make these suggested changes
obsolete. But I suspect the current download mechanism will be around
for at least a little while longer, so adding these corrections and
improvements will still be helpful.

• ErrorMessage():
• Check for InstallInstructions first. If custom instructions
  are available via that property, they should take precedence
  over the more generic message for PackageName.
• Rewrite the message for PackageName. The old error was
  incorrect. (For example, there was no "SDK installer" that
  would help resolve the error.) Additionally the new if
  statement in AddAttributeValue() removes some redundant
  appearances of this error, so the message can now provide more
  specific instructions.
• AddAttributeValue():
• Add if (sourceUrl.Name == null) to avoid logging unnecessary
  additional errors. MakeSureLibraryIsInPlace() now provides
  appropriate errors for each possible failure when
  sourceUrl.Name != null, so additional errors are only needed
  if sourceUrl.Name == null.
• ExtractArchive():
• Update the error message to account for the MD5 file names and
  the "zips" folder that were added in July 2015 (monodroid/master
  e8737f15c5e6f71f01f566475865a2cb34bfdfc9). Also remove the
  phrase "Please download" because re-downloading will not
  necessarily help with problems unzipping the file.
• MakeSureLibraryIsInPlace():
• Update the error message to account for the MD5 file names and
  the "zips" folder that were added in July 2015 (monodroid/master
  e8737f15c5e6f71f01f566475865a2cb34bfdfc9).
• Add a new explicit error with code "XA5217" for the case where a
  .zip file is extracted without error but is missing an expected
  nested archive. The old logic allowed the build process to
  continue even if all 3 attempts failed, and that could lead to
  some confusing error messages later in the build.
• Execute():
• Add parentheses and "Details:" to the second part of each error
  message because the file name of the missing item is usually
  much less important than the first part of the error message.

[brendanzagaeski]

This was just to test something about the GitHub pull request interface.