rootcling

### Motivatons:

* Faster builds because we can parallelize more if one rootcling invocation doesn't depend on the other.
  * The `G__source.cxx` generation doesn't depend on other `G__dep.cxx`. rootcling could run in parallel before.
  * But modules depend on each other. Module A (depends on B) needs to be generated by rootcling before Module B.
  * Now rootcling can't run in infinite parallel mode but needs to respect this dependency tree.
  * Generating all output files in rootcling is slow. 
* No interpreter garbage in the PCM/PCH like: `input_line_14`
* we want to piggyback on module build system instead of reimplementing it.
  * See CIFactory code when `COpts.ModuleName` is set.
  * In theory we could only have a callback from the module generation at `HandleTranslationUnit` where we convert comments to annotate attributes.

### General information


* rootcling Output files:

  - rootmap
    - Contains:
      - forward decls for templates:
      - class names/headers that are used to map from missing symbols to libraries to load.
    - ​
  - ROOT pcm
    - Is actually a ROOT file (surprise!)
    - layout information classes that we don't need to parse the header for loading the data structure
    - Can be replaced by C++ modules if same/similar performance (?)
  - C++ modules PCM
    - ​
  - G__source.cxx
    -

  ### Solution


  * Split the responsibilities of rootcling into different code parts:


    * Each code part is in its own binary.



    * User still has the old rootcling interface that just wraps those code parts.


      * Could also be done just by a shell script:

      * ```bash
        #!/usr/bin/bash
        root_module_gen "$@"
        root_rootmap_gen "$@"
        root_io_gen "$@"
        root_rootpcm_gen "$@"
        ```

    * But if people want a more parallel build they can just call each rootcling part in parallel.

    * Possible parts:


      * `root_module_gen` binary that generates a C++ module.

        * Is the only part that needs to respect the header dependency tree for modules.
        * Only compiles a C++ module and saves the ROOT annotations.
        * Generates a modulemap if needed:

          * If the user already has a modulemap, use this modulemap and perform sanity check if it's the same headers as passed on the command line.
          * If the user doesn't provide a modulemap, we generate a modulemap (where exactly this modulemap is generated is not decided yet) and load this modulemap.
          * CMake already generates a modulemap for users when the call `ROOT_GENERATE_DICTIONARY`.
          * We don't let `root_rootmap_gen` generate the modulemap file because:

            * Some libraries like `Core` don't have a rootmap but have a C++ module.
            * We could just drop `root_rootmap_gen` in the future without having to port the modulemap generation feature to `root_module_gen`.
      * `root_rootmap_gen` : Generates a rootmap file.

        * Could be dropped in the future when modules replace this functionality.
      * `root_io_gen` : Generates a `G__source.cxx`.
      * `root_rootpcm_gen`: Generates a `*_rdict.pcm` file.
        - Could be dropped in the future if modules replace this functionality without significant performance drawback.

    * Is the only binary in the rootcling ecosystem which depends