Make it clearer, where to find linting information in the wiki

.github/CONTRIBUTING.md

@@ -80,6 +80,9 @@ All the basic style conventions are defined inside the `package.json` (with the
 
 As indicated by [#238](https://github.com/Code-Inspect/flowr/issues/238) I decided to forbid `TODO`, `FIXME`, and `XXX` comments in code in favor of explicit *issues* directly on GitHub. Please do not try to get around that rule.
 
+For more information on the linter, how to call it (and automatically deal with some of the issues raised),
+please refer to the [Test](https://github.com/Code-Inspect/flowr/wiki/Linting-and-Testing) wiki page.
+
 ## Releases
 
 Releases are to be scheduled by the administrators of the repository. Please do not try to create a release yourself.

wiki/Test.md → wiki/Linting and Testing.md

@@ -47,7 +47,6 @@ Besides folders can (theoretically) arbitrarily structure their tests. We use th
 - `*.spec.ts` denotes a test file which is to be collected when all tests are run, it may require other files to avoid big testing files and improve structure, but those should never end in `*.spec.ts`.
 . `-tests.ts` denotes test files which are required by `*.spec.ts` files. To require them, there is also the helper function `requireAllTestsInFolder` which performs sanity checks to avoid forgotten tests.
 
-
 #### Writing a Test
 
 Currently this is heavily dependend on what you want to test (normalization, dataflow, quad-export, ...) and it is probably best to have a look at existing tests in that area to get an idea of what comfort functionality is available.
@@ -96,16 +95,10 @@ And a weaker version of the first (allowing for *todo* comments) which is run au
 npm run lint-local
 ```
 
-Besides checking coding style (as defined in the [package.json](../package.json)), the linter runs the [license checker](#license-checker).
+Besides checking coding style (as defined in the [package.json](../package.json)), the *full* linter runs the [license checker](#license-checker).
 
 If you are unaware, several linting problems can be automatically fixed by [eslint](https://eslint.org/docs/latest/use/command-line-interface#fix-problems). So you may be fine by just running:
 
-```shell
-npm run lint -- --fix
-```
-
-Similarly, for `lint-local`:
-
 ```shell
 npm run lint-local -- --fix
 ```

wiki/_Sidebar.md

@@ -3,7 +3,7 @@
   * [Overview](https://github.com/Code-Inspect/flowr/wiki/Overview)
   * [Interface](https://github.com/Code-Inspect/flowr/wiki/Interface)
   * [Core](https://github.com/Code-Inspect/flowr/wiki/Core)
-  * [Testing](https://github.com/Code-Inspect/flowr/wiki/Test)
+  * [Linting and Testing](https://github.com/Code-Inspect/flowr/wiki/Linting-and-Testing)
 * Extra Information
   * [Terminology](https://github.com/Code-Inspect/flowr/wiki/Terminology)
   * [R's Capabilities](https://github.com/Code-Inspect/flowr/wiki/Capabilities) & [Tokens](https://github.com/Code-Inspect/flowr/wiki/Tokens)