Different Adapters sharing code: inheritance or composition over inheritance

From https://github.com/BHoM/BHoM_Adapter/pull/164#issuecomment-567298001

We have this situation:
1. Base BHoMAdapter is `abstract` and we want it to be that way. The base Adapter has to be as discipline agnostic as possible.
1. We have large chunks of code repeated in many Adapter implementations; in particular, this happens for all those adapters falling _Structural Analysis_ discipline. AFAIK, it does not happen in any adapter which doesn't fit in that category.
1. That repeated code cannot live within the base Adapter, specifically because it requires a specific discipline oM and/or Engine (_Structural_).

While I appreciate the advantages of composition over inheritance, I see this as a good application of inheritance.

A valid counter-argument is:
> A simple although not frequent case for that would be a multi-discipline adapter.

I'd like to have other opinions on this. Do we want to allow for the concept of a _multi-discipline adapter_ right now? I think it is already a rarity that multiple adapters share large code chunks, like it happens for the Structural Analysis ones; it is a case uniquely determined by the sharing of a same _intent_ (discipline), much like we do for the `Engine` division in different types.

As I envisioned it, we won't need any additional base Adapter other than `BHoMAdapter` _and_ `StructuralAnalysis` Adapter, unless it is determined that many new adapters start to share large code chunks.

Happy to change my mind.
I'd like this issue to become a space for everyone to chip in and agree on the way forward, while avoiding a full stop to the Refactoring Level 4 PR.

@al-fisher @adecler @FraserGreenroyd @JosefTaylor @rwemay @epignatelli @IsakNaslundBh

Start by reading the issue discussion and reviewing the abstract BHoMAdapter alongside the StructuralAnalysis adapter implementations mentioned in the proposal. Compare the repeated Structural Analysis code and the multi-discipline concern before proposing a direction. Done means the project has agreed on an inheritance or composition approach and a clear refactoring plan.

Written by the indexing model from the issue text.