Overly specific implicit Windows `os` package

### Problem

Windows gone did an update overnight, and suddenly all of my packages stopped resolving, saying:

```bash
$ rez env python
The context failed to resolve:
The following package conflicts occurred: (os-windows-10.0.17134 <--!--> ~os==windows-10.0.17763)
```

And after staring myself blind at this seemingly contradictory line, I spotted the last 3 digits have increased since yesterday.

Windows isn't good for much, but it's really good at backwards compatibility. It would be safe to strip those last 3 digits I think. Heck, it'd be safe to strip almost every digit, as anything working on Windows XP is likely still compatible with Windows 10.

On Linux, the implicit packages are specific enough I think.

```bash
~platform==linux (implicit)
~arch==x86_64 (implicit)
~os==Debian-9.7 (implicit)
```

Here's what they look like on Windows.

```bash
~platform==windows (implicit)
~arch==AMD64 (implicit)
~os==windows-10.0.17763 (implicit)
```

### Solution

Would recommend making this level of specificity opt-in, to avoid newcomers from falling into this trap. How about a default of 2 digits, e.g. `windows-10.0`?

Start by reproducing `rez env python` on Windows and tracing where the implicit `~os` package version is generated. Done means the default Windows version is less specific, such as `windows-10.0`, while a configuration option can restore more specific versioning without breaking package resolution.

Written by the indexing model from the issue text.