add std/rtti and getDynamicTypeInfo

[timotheecour]

• pretty much all languages that support type hierarchies have this feature, eg:
  • C++ typeid returning a type_info refs https://en.cppreference.com/w/cpp/language/typeid
  • D: typeid returning a TypeInfo refs https://dlang.org/spec/expression.html#typeid_expressions
  • C#: GetType refs https://docs.microsoft.com/en-us/dotnet/api/system.object.gettype?view=net-5.0
  • swift: type(of:) refs https://developer.apple.com/documentation/swift/2885064-type
  • java: getClass https://www.tutorialspoint.com/java/lang/object_getclass.htm
• works with regular gc (gc:refc) or nimV2 (eg gc:arc|orc)
• fixes rtti: getDynamicTypeInfo timotheecour/Nim#573

use cases

• user defined better error messages
• debugging
• writing gdb/lldb plugins in nim and exploring runtime type
• also asked in nim chat: in the irc log of the conversation (see also further down).

notes

• std/rtti is a new module and hidden behind -d:nimExperimentalTypeInfoCore so this module can more freely evolve until it stabilizes, while at same time allowing people to try it as opt-in, refs nimExperimentalFoo for experimental modules/APIs timotheecour/Nim#575
• I intentionally didn't add that API inside typeinfo which is about the Any type, whereas getDynamicTypeInfo is about runtime type information (in particular for polymorphic types, but also useful for non polymorphic ones), but both can be combined
• the diff in sytem.nim is to avoid Error: system module needs: programResult for tests/dll/nimhcr_integration.nim
• turned hti include module into a private import module std/private/hti to avoid it being included more than once (and because imports are cleaner in general)

future work

• move definition of TNimTypeV2 to hti.nim now that hti is a proper import module, so that it can be deduplicated from system.nim and std/rtti (alternatively, I could do this in this PR)
• see whether lib/system/cyclebreaker.nim can reuse this proc instead of it defining its own proc getDynamicTypeInfo[T](x: T): PNimTypeV2 {.magic: "GetTypeInfoV2", noSideEffect, locks: 0.}
• maybe also expose a common API in std/rtti that would work with both gc:refc and gc:arc, eg via getters getSize, gteAlign, getName etc

[Araq]

This should be opt-in, the type names might not always be available (I can think of v2 implementations that use integers and modulo operations for the of operator). Also, the type names are generally of little use -- you cannot construct objects via the type name and the runtime reflection capabilities of Nim are weak.

[Varriount]

Is there any plan for the design of this module? I'm assuming users are going to want more functionality than just the single function retrieving and comparing type information objects for equality.

[Araq]

This needs an RFC.

[Araq]

As I said, this needs an RFC first.