[<NUnit.Framework.SetUpFixture>] changes initial state for reserved words testing.

[EricGT]

For testing of mutable reswords in the printer module, the test rely on the state of reswords being as it would be if the script was run without [<NUnit.Framework.SetUpFixture>].

In the parser module "//" is added to reswords with

reserve_words ["//"]

which now changes reswords before the test starts causing the test to fail.

Maybe each module can be initialized after the test for that module are completed instead of initializing all of the modules up front.

I think when we are done we will have enough knowledge about the mutables to write specific functions to manage the mutables not only for testing but for restoring the state of similar to the checkpointing done with OCaml.

[jack-pappas]

@EricGT I implemented the ModuleReset module in SystemState.fs specifically to handle scenarios like this. I've only put the skeleton together, we'll need to work together to fill in the logic to actually reset mutable state values to their default/initial values.

For example, you could add some code to the parser function to reset reswords to it's default value:

NHol/NHol.Tests/SystemState.fs

Line 201 in 9b214b1

// TODO

For consistency, the functions in ModuleReset should be written so that they essentially re-execute the initialization process for that module; to keep it simple, each function should only handle it's own specific module -- the new setup functions I added to each test module call the ModuleReset functions in the correct order so that the modules up to, but NOT including, the module under test will be re-initialized in the same way they were initialized.

The other thing we need to address -- throughout the code, there are a number of locally-scoped (i.e., private or captured) values which hold some mutable state. There's no easy way to reset these as-is, so wherever possible, I've been lifting them out of their scope and marking them 'internal' so we can directly reset them from within the ModuleReset functions; in addition, I've also been renaming these values by prefixing them with the name of whatever value/function I lifted them out of to avoid any naming clashes.