Improve clearing Fennels macro-loaded table when needed.

[rktjmp]

Lua is retaining macros modules in memory, so edits to macro files are not reflected in auto-builds without restarting neovim.

Fennel retains a package.loaded style list of macro modules it has seen, which we need to clear, exists as macro-loaded in specials.fnl, but appears to be exposed on the compiler env at some points.

[rktjmp]

    (each [k _ (pairs fennel.macro-loaded)]
      (tset fennel.macro-loaded k nil))

in compiler.compile-string fixes issue, but means every compile call will fetch and compile macro modules.

• Will give slower compile performance:
  • make (manually) -- probably not a huge deal, the act of typing is probably slower than the build,
  • auto-make (on save) -- noticeable,
  • diagnostics (during editing) -- will extend delay when leaving text buffer ,
  • require (when compile needed).
• Will give better UX when:
  • Editing files that have had macros change (eg: adding x to m1 wont show "m1 does not have x function" when importing it without restart.
  • auto-make (actually functional), this is probably the bigger issue as it can "say" building was all ok but the macros have not changed, so the code has not changed.

In some respects I think the performance isn't a huge deal. Compiling is already "slow" compared to anything else, so it being a bit slower (probably not to a noticeable degree unless the given files use lots of complex macros) might be a reasonable trade off for the better diagnostics and clearer-functioning auto-make.

Potentially the compile could be run in its own thread, which gets its own state. Either a fresh thread could be built per-compile-entry (probably not "per compile call"), which would incur some start up time and "config" time where hotpot is loaded again, etc (this is ~7-8ms), or a persistent thread could exist that compiles when needed, and nukes the macros-loaded table each time but the performance hit wont be as "felt".

The off-thread compile has been considered before (#92, was blocked waiting on nvim 0.8) when working on ruin.fnl which has very complex macros, and is particularly slow when editing large test files that generate 10x lua code.

Next:

• See viability of only nuking when make is running. Passing an extra flag to the compiler? The check requires fennel in memory, but that could be checked "in make"? If fennel exists, nuke the table, otherwise there is no need, fennel will load in the compiler fresh anyway. Least impact on performance, adds another "quirk" to that branch.
• Otherwise include the above each loop.

Then,

• See viability of off-thread compilation.
  • adds dragons, might still be worth it.

[rktjmp]

Mitigation in 9297ab3