Validate compression method in all ZipFile.Add overloads

[Numpsy]

… to validate the method themselves, and throw consistent exceptions for unsupported methods

Related to the discussions in #333 and some of the issues that occur when adding extra compression methods due to using ZipEntry for compression method validation:

There are currently the following methods in ZipFile to add a new entry and specify a compression method to use:

public void Add(string fileName, CompressionMethod compressionMethod, bool useUnicodeText);
public void Add(string fileName, CompressionMethod compressionMethod);
public void Add(IStaticDataSource dataSource, string entryName, CompressionMethod compressionMethod);
public void Add(IStaticDataSource dataSource, string entryName, CompressionMethod compressionMethod, bool useUnicodeText);
public void Add(IStaticDataSource dataSource, ZipEntry entry);

(there is also one that just takes a ZipEntry which only accepts 0 length entries, so i'm not sure if this applies to that one).

Out of those:

The first two check if the compression method is supported themselves, and throw ArgumentOutOfRangeException if it isn't.

The next two don't check themselves, but use the CompressionMethod property setter on ZipEntry, which throws NotSupportedException for methods it things are unsupported.

The final one does no checks, which ends up relying on the property setter in ZipEntry I think? (could hypothetically be an issue if you read an entry with an unsupported method from an existing file?)

This PR makes two changes:

1. do explicit validation in the Add functions, and throw ArgumentOutOfRangeException for unsupported methods,

2. Use a local method to decide what is supported instead of deferring to ZipEntry (it's ZipFile that knows what it supports after all).

This somewhat counts as an API change as it changes the exceptions thrown by a couple of the functions from NotSupportedException to ArgumentOutOfRangeException (i'm not sure which exception is best to use, though as ArgumentOutOfRangeException is the one that is specified in the doc comments and NotSupportedException isn't documented, that seemed the simple one to standardize on)

I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.

[piksel]

I think NotImplementedException is the one we should use (if that's the case of course). Since both NotSupportedException and Argument*Exceptions indicate that the operation or argument is invalid.
ArgumentOutOfRangeException is also just true on a machine level. An enum is not really a number, it's a token for a commonly understood API concept.

That being said, NotImplementedException is most commonly used when not implementing parts of an interface, so NotSupportedException might still be better. The documentation does not have any scenarios matching ours unfortunately.

[piksel]

This just reads out as being wrong. Why would ZipFile ask an entry if it supports compressing it?

[Numpsy]

Yes, it seems inside out.

[piksel]

Looks good! I am not sure about what to do with the exception, though. But I'm fine with it if you want to stick with it.

[Numpsy]

NotImplemented sounds better than ArgumentOutOfRange, I can change that if you're ok with changing the documented excdeption types on a couple of functions.

[Numpsy]

Related: ZipOutputStream.PutNextEntry is in a similar situation with not validating the compression type is supported, and it could perhaps do with throwing the same exception type there.

[piksel]

Yeah, they should probably use the same exception.

The change in API should not be a problem, since this is not an exception that is usually catched by the consumer and handled. Instead, most people would just see it whenever they attempt to use a feature that is not supported by the library (yet).

[Numpsy]

Exception changed to NotImplementedException

[Numpsy]

rebased on top of #420 to fix a merge conflict