better extend cycle detection

[jurgenvinju]

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, when reloading 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 not directly 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.

[codecov]

Codecov Report

❌ Patch coverage is 22.80702% with 132 lines in your changes missing coverage. Please review.
✅ Project coverage is 47%. Comparing base (d07960b) to head (c78fce9).
⚠️ Report is 172 commits behind head on main.

Files with missing lines	Patch %	Lines
src/org/rascalmpl/semantics/dynamic/Import.java	30%	52 Missing and 8 partials ⚠️
...g/rascalmpl/interpreter/env/ModuleEnvironment.java	11%	30 Missing ⚠️
...g/rascalmpl/interpreter/env/GlobalEnvironment.java	21%	25 Missing ⚠️
src/org/rascalmpl/library/Messages.java	0%	7 Missing and 1 partial ⚠️
...scalmpl/interpreter/staticErrors/CyclicExtend.java	0%	4 Missing ⚠️
...l/interpreter/staticErrors/CyclicImportExtend.java	0%	4 Missing ⚠️
...rc/org/rascalmpl/ideservices/BasicIDEServices.java	0%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##              main   #2392    +/-   ##
========================================
- Coverage       47%     47%    -1%     
- Complexity    6571    6578     +7     
========================================
  Files          782     783     +1     
  Lines        64531   64634   +103     
  Branches      9656    9672    +16     
========================================
+ Hits         30548   30562    +14     
- Misses       31620   31697    +77     
- Partials      2363    2375    +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jurgenvinju]

The next challenge is extending modules which haven't fully loaded yet. This may happen in complex but correct configurations where a given module's imports and extends eventually trigger an extend of itself.

The recursive module loader does not currently recognize this situation and extends only what is currently registered in the module. This then leads to errors of the "undeclared x" kind.