Fix leading slash in ZIP archive

[GerardSmit]

Fixes #102

Backward Compatibility

When you've created a ZIP archive with version <0.21, all entries will start with a / in the entry name.

To ensure we don't mismatch new entry names, I've introduced a new property:

class ZipArchiveFileSystem
{
	/// <summary>
	///    Gets or sets whether entries in the archive should have a leading slash.
	/// </summary>
	/// <exception cref="InvalidOperationException">Cannot change LeadingSlashInArchive when the archive already contains entries</exception>
	public bool LeadingSlashInArchive { get; set; }
}

When opening a ZIP archive from version <0.21 (or when there is a leading slash in the ZIP entry name), this property will be set to true.
For new ZIP file systems, it will be set to false. ⚠️ (This is a breaking change)

When this property is set to true, all new entries will have a leading slash.

I've created two ZIPs (one before the change and one after the change) to validate that both the old and new ZIPs work correctly.

Recursive Rename/Deletion

While debugging, I found another bug.

When you have a directory name that starts with the same prefix as other directories in the same path, it would:

1. Move the wrong directories.
2. Delete the wrong directories.

For example:

dir\
	file.txt

dir-suffix\
	file.txt

unrelated\
	file.txt

When you remove dir\, it would also remove dir-suffix\. This obviously shouldn't happen.

Other Changes

1. Moved test ZIPs to sub-directories and added a README explaining the content.
2. When moving directories, we don't copy the entry Stream (which is empty; it's a directory..) anymore.
3. Added .NET FX target back in Unit Tests (otherwise, I couldn't validate .NET Standard 2.0 / .NET FX).

Note: .NET Standard 2.1 is not being tested. .NET 8.0 and 9.0 have a direct match, and .NET 10.0 uses the .NET 9.0 library version.