nimExperimentalFoo for experimental modules/APIs

[timotheecour]

proposal

allow iterating in a more effective way on new modules (or even new APIs in existing modules), as follows in this example:

# in std/sysrand.nim
when defined(nimExperimentalSysrand):
  # rest of code ...

so that:

• this module remains hidden by default, but people can easily try it in devel with explicit flag -d:nimExperimentalSysrand; more eyeballs => higher likelyhood to find bugs/design issues
• more than 1 person can easily contribute to it
• no need to constantly rebase long running PR's and resolve conflicts since they'd be merged faster
• we can more freely iterate without fear of breaking changes for regular devel users

Unlike the proposal discussed in nim-lang/RFCs#310, there'd be no need for std2 namespace, and no need for introducing an experimental namespace (which has the issues of causing problems when module is moved), since the only difference once module is stabilized is that the flag -d:nimExperimentalFoo would not be needed anymore;

so we don't have this problem raised in nim-lang/RFCs#310:

But now we created a situation where it's better to import experimental / module! Because that's the import that actually works with older versions of Nim! So client code becomes:

This is essentially a lightweight form of --experimental:foo that can be used for new (non-trivial) modules/API's.

note

if a vmops is needed this works:
when defined(nimExperimentalSysrand) or defined(booting):