Update the GitHub workflow configuration to test on both, Linux and
Windows.

We use `newSink` to decide where the zap.Config.OutputPaths field
intends to send logs. It can be in the form,

    file:///foo/bar
    # or equivalently,
    /foo/bar

Or a user can register a custom sink constructor with `RegisterSink`,
and then use the specified scheme in the output paths.

    zap.RegisterSink("myscheme", ...)

    zap.Config{
        OutputPaths: []string{
            "myscheme://whatever/I/want",
        },
    }

This method of configuration hasn't worked for Windows (ref #994)
because we use `url.Parse` to parse these output paths.

`url.Parse` parses a Windows file path like `C:\foo\bar` to the URL:

    URL{
        Scheme: "c",
        Opaque: `\foo\bar`,
    }

This commit adds support for Windows file paths.
It does so by converting "\" symbols in the output path with "/"
before attempting to parse it with url.Parse. This gives us,

    URL{
        Scheme: "c",
        Path: "/foo/bar",
    }

Following that, we check if the scheme matches the path's "volume name".
On Windows, the volume name of `C:\foo\bar` is `"C:"`.
On Unix, the volume name of all paths is `""`.

This lets us convert the partial file path in the URL
back to a valid Windows file path
and set the scheme to "file" to use the file sink.

If we register a factory with the scheme `m://` on Windows,
matching blindly on just the volume name will turn
`m://foo/bar` into `file://m:\foo\bar`.

We need to do the `file://` conversion only if we didn't find a factory
with the name in the path.

`strings.HasPrefix(.., '/')` is Unix specific.