Revisit Seekability of writable zip streams

In PR #1311 (issue #585) two writable streams ([Certificate.cs](https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/WindowsBase/MS/Internal/IO/Packaging/Certificate.cs#L134) and [XmlDigitalSignatureProcessor.cs](https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/WindowsBase/MS/Internal/IO/Packaging/XmlDigitalSignatureProcessor.cs#L940)) get wrapped in a memory stream by calling the new method `GetSeekableStream(FileMode.Create, FileAccess.Write)`. It is unclear from the PR source how the written data will be propagated to the actual zip stream. Since this was noticed after the PR merged I'm opening a separate issue to revisit the handling of writable streams.

I'd also argue that the current implementation of [GetSeekableStream](https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/Shared/MS/Internal/IO/Packaging/PackagePartExtensions.cs#L60) should not have had `FileMode` and `FileAccess` paramters, since the only case which is handled correctly is the open/read combination.

I'd suggest either providing a dedicated stream wrapper class and keeping FileMode/FileAccess, or remove FileMode/FileAccess and provide a separate code path for callers who want to write data.

Related: issue #1363 apparently still has call sites which do not get wrapped