Fix PAX extended attribute reading logic to treat '=' character as valid in the value strings.

[carlossanlop]

Fixes #81699

We had logic in TarHeader.Read.cs that was explicitly forbidding the '=' character as part of the body of the value string in an extended attribute key-value pair. It felt natural to have such restriction in place as it is one of the two separators that the spec indicates:

• The '=' character is used to separate a key from a value.
• The '\n' character is used to separate a key-value-pair from another.

But the restriction is not needed: We only need to find the first '=' character to stop reading a key and start reading a value, and after that, we can keep reading any character, including any number of '=' characters, until we detect a '\n' character. Additionally, none of the specs indicated that the '=' is forbidden in values.

This issue was reported by a customer, so we would like to consider a backport to 7.0.

[carlossanlop]

While working on this, I realized we should disallow adding key-value-pairs in which the key contains '=', or in which either the key or the value contain a '\n'. Both cases will cause the extended attribute reading logic to fail.

I'll add the fixes to this PR unless anyone indicates a preference to have the two issues fixed separately.

[jeffhandley]

Separate sounds good to me. Would those other changes potentially be breaking?

[carlossanlop]

Would those other changes potentially be breaking?

I don't think adding the exception would be breaking because we would be shielding the user from unexpected behavior and corrupted data due to improper use of reserved characters in the key or values.

[carlossanlop]

/backport to release/7.0

[github-actions]

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/4370450091