Improvements/reconsidering the Adapter set-up and Modules mechanisms

#### Description:

As seen here: https://github.com/BHoM/ETABS_Toolkit/pull/422#pullrequestreview-1330130615

We had an unpredicted failure because of the following:
- we are constructing the functionality at runtime of a class (ETABS_Adapter) from within the class' constructor;
- this functionality depends on another service (modules) which itself depends on the correct configuration of the class (ETABS_Adapter's Id).
- The service module is not injectable via the ctor but is required to exist independently.

Because we had the incorrect ordering of instructions in the ctor (we declared the modules before the setting of the AdapterId), this raised a failure in the module loader, which required the AdapterId to be set.

### Ideas

Possible solutions commonly adopted that require reworking the current architecture are:
- Dependency Injection: e.g. ctor injection via an IoC container
- Inheriting a base abstract adapter that exposes the functionality

Other solutions keeping current architecture are:
- adding the dependency on AdapterId on the modules
- making sure AdapterId is set before entering the ctor:
- adding a static ctor
- setting it as default value, never inside the non-static ctor

Start with the linked PR #422 review, then inspect the ETABS_Adapter constructor, AdapterId initialization, and module-loading mechanism described in the issue. There are no files or tests named; done requires choosing and documenting one architecture that removes the initialization-order failure and validating the resulting adapter/module behavior.

Written by the indexing model from the issue text.