We detected several serious issues with extend cycle detection in the interpreter:

• When module loading fails due to a cyclic extend, the current module is not cleaned up and left as a "zombie" #2390
• Extend cycle detection can be spoofed by confusing imports halfway #2388
• Extend cycle detector of interpreter skips root module #2387

The current PR should fix these in one go. This is the idea:

• remove cycle detection from the recursion that loads imported and extended modules
  • this results in a fully loaded module graph, with extends/imports dependencies
  • the extend edge that completes a cycle is never implemented this way, leaving modules half-extended (see below)
• detect cycles in the loaded module graph, after every module is finished loading
  • this is a simple algorithm, albeit a bit more expensive than the previous solution
  • cycles will be detected with accuracy (no more false positives or negatives)
  • cycles may be detected several times (for every element of a cycle)
• report cycles to the user, but do not unload half-loaded modules anymore
  • half-extended modules (due to the missing effect of the final extend) will remain in memory
  • eventually, whenreloading is activated, this results in an accurate image of the dependencies
    which informs the reloading algorithm and improves its correctness
  • half-loaded modules will alway be unlinked from the REPL environment (unImported and unExtended),
    such that the user can notdirectly access any half-loaded modules.
  • users should understand that after a cycle is detected the semantics of module
    extend is not fully implemented and function overloads, global variables and data type definitions
    may be incomplete.

The above rationalizes the cycle detector and improves the correctness of reloading without touching
the reloading code.

As a side-effect, all other errors detected in modules (static errors and such) will also change a bit:

• before a module with a static error would be unloaded from the heap. This would cause a gap
  in the dependency graph, leading to strange effects of the reloader
• with this PR the module will remain in memory, but inaccessible from the REPL. After reloading
  fixes the error, everything will be in order again.

This PR's implementation is finicky and W.I.P.