[Request] Future of std/registry for Windows

[awr1]

The current registry module is kind of sparse and has an unstable API, there are definitely some enhancements that I think could be made here:

• Make module available at compile-time - this can be useful for interfacing with certain libraries and other utilities, e.g. getting path for Windows SDK. My one worry is that the Nim compiler might trip AVs depending on what procs are exposed - but it might not since registry manipulation is a common activity for many applications.
• / path joining procedure similar to std/os module. (Maybe we should just export the std/os one, since registry paths on Windows also use \ for splits)
• Support for all registry types
• hasKey for key detection
• getKey (return a variant type?)
• Subkey enumeration iterator
• Key deletion, key tree deletion
• Aliases like HKLM, HKCU for root keys

The alternative is that we renege on this and deprecate the module for the standard library and instead just make it a nimble one, but with that we could lose the possibility for compile-time procedure calls (especially because compile-time FFI beyond the core standard library/nimscript stuff is up in the air)

[Araq]

Something for "fusion".

[rominf]

It would be useful to have: hasKey and getKey which returns a variant type because of nim-lang/RFCs#343.