or: Unable to implement 'uname' on Python due to recursive call
or: platform.uname() should avoid calling `uname` in a subprocess


In [this issue](https://github.com/jaraco/cmdix/issues/1), I stumbled across a strange and somewhat unintuitive behavior. This project attempts to supply a `uname` executable implemented in Python, so that such functionality could be exposed on any platform including Windows.

What I found, however, was that because the stdlib `platform` module actually invokes `sh -c uname -p` during most any call of the module (https://github.com/python/cpython/blob/9db56fb8faaa3cd66e7fe82740a4ae4d786bb27f/Lib/platform.py#L836), attempting to use that functionality on a system where `uname` is implemented by Python (and on the path), will probably fail after a long delay due to infinite recursion.

Moreover, the _only_ call that's currently invoking `uname` in a subprocess is the `processor` resolution, which I suspect is rarely used, in part because the results from it are inconsistent and not particularly useful.

For example, on Windows, you get a detailed description from the hardware: 'Intel64 Family 6 Model 142 Stepping 9, GenuineIntel'

On macOS, you get just 'i386'.

And on Linux, I see 'x86_64' or sometimes just '' (in docker).

To make matters even worse, this `uname -p` call happens unconditionally on non-Windows systems for nearly any call in platform. As a result, it's impossible to suppress the invocation of `uname`, especially when functionality like `pkg_resources` and its environment markers is invoked early.

I suggest instead the platform module should (a) resolve processor information in a more uniform manner and (b) not ever call uname, maybe [with something like this](https://github.com/jaraco/cmdix/blob/d61e6d3b40032a25feff0a9fb2a79afaa7dcd4e0/cmdix/command/uname.py#L53-L77).

At the very least, the `uname` call should be late-bound so that it's not invoked unconditionally for rarely-used information.

After some period for comment, I'll draft an implementation.