Refactoring tasks

[satfra]

Ongoing cleanup tasks:

• More namespaces: Currently, most things reside in the master DiFfRG namespace. This clutters in particular the Doxygen documentation massively. I'd propose to move most of the existing code into nested namespaces and making them available in the parent namespace DiFfRG through using declarations.
• Fill in missing documentation.
• ...

[keiwanjamaly]

Maybe, one can utilise an LLM for this. Maybe also for #7.

[keiwanjamaly]

I had the idea, that one could overwork the configuration_helper.hh and the variable access to be more class like. By that, one could also provide default wich would work for most cases. I'm thinking of something like a config structure (or class)

struct Config {
    uint fe_order = 2;
    uint threads = 0;
    uint batch_size = 8;
    uint overintegration = 0;
    // ...
};

one could also split this up further.

struct DiscretizitaionConfig /* I think here the convention is CamelCase */ {
    uint fe_order = 2;
    uint threads = 0;
    uint batch_size = 8;
    uint overintegration = 0;
    // ...
}

struct IntegrationConfig {
    // ...
}

struct Config {
    DiscretizitaionConfig discretizitaion;
    IntegrationConfig integration;
    // ...
};

The benefit is, that testing would become much simpler since a json does not need to be provided anymore, only the configuration where default parameters could be utilized. Much more simpler is the testing of sub routines like integrators, etc. Also parsing and type checking would be handled at one point in the code, before the flow.

To handle the parsing and type checking, if a .json is provided, one could write a factory