proposal: os: expose all possible path and pathlist separators

[defaulterrr]

Description

As of right now, os (and by extension, filepath) package exports os.PathSeparator and os.PathListSeparator constants that are tied to the system the binary is built on (by //go:build constraints). So, for example, on unix systems, these would be / and :. The problem with this approach is that there is no way to reference a Windows separator from a unix-built binary, and vice versa. While this might be a rare occasion, sometimes there is a need for that (i.e. if some unix-style binary requires unix-style separators even when executed in Windows environment, or if you need to render a help docstring for the user).

Of course, you can always get around this and just declare your own separators but that just feels hacky when there is an exposed const in the standard package.

I'd be happy to submit a PR for this

Proposed changes

What i propose is adding new constants to the os package that would reference each style, and only typealiasing them in _<os>.go files. This will not break existing external API, only expose new constants (that are already present in the library, but just not exposed due to build constraints).

In os package:

// src/os/path_unix.go

const (
	PathSeparator     = UnixPathSeparator // OS-specific path separator
	PathListSeparator = UnixPathListSeparator // OS-specific path list separator
)

// src/os/path_windows.go

const (
	PathSeparator     = WindowsPathSeparator // OS-specific path separator
	PathListSeparator = WindowsPathListSeparator // OS-specific path list separator
)

// path.go

const (
	UnixPathSeparator     = '/' // unix-specific path separator
	UnixPathListSeparator = ':' // unix-specific path list separator
        WindowsPathSeparator     = '\\' // windows-specific path separator
	WindowsPathListSeparator = ';'  // windows-specific path list separator
)

[willfaught]

It seems unusual to expose info about non-native platforms in the stdlib. Perhaps these should be in x/sys/{unix,windows} instead?