Refactor PackageProps to make the Yaml loading and processing methods common

[JimSuplizio]

All I'm doing here is refactoring some of the code that was in PackageProps, specifically around Yaml loading and processing, hoisting it out to be common and usable outside of that class. Specifically, I'm going to be using the yaml loading and processing for the Get-AllPackageInfoFromRepo I'm implementing for Java.

The changes are as follows:

1. LoadAndCompatibleConvertFrom-Yaml (this was renamed to LoadFrom-Yaml as per feedback) - this was originally part of the PackageProps::ParseYmlForArtifact function. I moved the Test-Path verification of the yml file and try/catch surrounding the call to CompatibleConvertFrom-Yaml into a common function. That way anyone using the CompatibleConvertFrom-Yaml doesn't have to dupe the checks or the try catch.
2. GetValueSafelyFrom-Yaml - this was originally PackageProps::GetValueSafely and hidden. I could have changed the class to unhide and make the function static but it seemed better to be hoisted out and sit alongside the rest of the functions in Package-Helpers. The one thing I changed in this function was that if the key isn't found or the value is null, it writes the key and the full path into the output. In theory this could have thrown but there are scenarios where we can look for something that might not exist in a yml file. An example of this would Java's AdditionalModules which may or may not exist.

For testing, to ensure I was running the code path our pipelines run, I just executed /eng/common/scripts/Save-Package-Properties.ps1 locally against my Java repo to create the PackageInfo json files for various service directories. I pulled the PackageInfo directories directly from their respective pipelines and used Beyond Compare to verify the output. The differences were that the json files from the pipelines had Namespaces and this was expected. In a Java pipeline, the PackageInfo files are created before the build and Namespaces are added to them after the build.

[azure-sdk]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

[scbedd]

Gave some feedback, but I don't think anything that would block.

[azure-sdk]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

[JimSuplizio]

Gave some feedback, but I don't think anything that would block.

Yup. I made changes for all your feedback. Everything made sense and the changes were trivial.