Handle invalid Azure object metadata keys

[Neon-White]

Explain the changes

1. The new code should adhere to azcopy's method of resolving invalid object metadata keys in Azure

The key of the newly added header is azure-metadata-handling, and its possible values are:

• RenameIfInvalid - which will rename the key in order to preserve it (which is the default behavior if the header is not supplied)
• ExcludeIfInvalid - which will exclude the invalid tag
• FailIfInvalid - which will fail the upload

We support the same naming and recovery methodologies as Microsoft, meaning we won't be able to discern between tags whose renamed form cannot be restored (e.g. - !@# and #$% on the same object)

Issues: Fixed #xxx / Gap #xxx

1. Fixes object IO when the object contains metadata keys that are invalid by Azure's standard

Testing Instructions:

1. Upload an object with metadata keys containing non-alphanumeric characters (e.g. !@#-) to a bucket backed by an Azure namespacestore
2. Download the object from the bucket
3. Verify that the tags are the same as they were originally
   Bonus step:
4. After 1, download the object directly from Azure, and verify that it now contains two new metadata keys related to the invalid one, starting with rename_ and rename_key_

[romayalon]

Is there a situation where meta data is passed but this header isn't?

[Neon-White]

I believe that this is the default situation where a user simply uploads objects with md - it's a header I made up that should be supplied by the user if they want to choose a specific behavior

[dannyzaken]

squash your commits