Refactoring and documentation based on "Universal" common interfaces

Broken rules:

There are some keys interfaces that drive everything, defining the formal structure, dependency and organization of the BHoM.

We need to push a reorganization of their arrangement, tweak some conventions and namings, and relocate appropriately certain Engine methods that use/depend on them.

Suggestions to restore compliance:

WIP diagram:

Engines

BHoM_Engine

• Move the IGeometry and IGeometry3D methods into the Geometry_Engine.

Analytical_Engine-Graphics_Engine

• Methods that generalize the IResult representation.

Results_Engine

The Results engine should be deleted, as it currently depends on Structure_oM and Analytical_oM and Graphic_oM and its categorization is not meaningful.

• Move the Max, Min, Total, AbsoluteMax methods into Structure.Query.
• Move the DisplayMeshResults into Graphic_oM. Add Analytical_oM dependency in Graphic_oM.
• Move Analytical_Engine: Group, IsNull, MapResults (to be renamedMappedResult).
• Delete the Result_Engine.

Reflection_Engine

• Review / action the historic issue: https://github.com/BHoM/BHoM_Engine/issues/1645. Current thought is that if we move all methods that can be moved from the Reflection_Engine in the BHoM_Engine, what remains really is something that should be placed in a Code or Framework Engine? i.e. is Reflection the right name anymore?

Any objects/methods left obviously is code that is needed as part of the Framework for Adapters, UIs etc. and is distinct from the already existing Programming namespace that is "Programming as a discipline". i.e. creating Programming representation of a concept much like a Structural or Acoustics representation say

Object models

Base_oM

• Add description to the BHoMGroup and IBHoMGroup.
• Move the ISpecification interface in the CIH_Toolkit.
• Review the ComparisonConfig and if it makes sense to move it in the Diffing_oM.
• Review the usage of ISettings interface - if not used, remove; or see if it can be moved below.

Analytical_oM

• https://github.com/BHoM/BHoM/issues/1260
• Reformulate the IResult interface, including creating a compositional set of interfaces: IResult, IObjectResult, ICaseResult, ITimedResult, Structure.IResult
• Formalize the requirement of the IResult interface: a flat list of data primitives.

Graphical_oM

• https://github.com/BHoM/BHoM/issues/1261

Reflection_oM / Programming_oM / Data_oM

• Review / action the historic issue: https://github.com/BHoM/BHoM_Engine/issues/1645. And see above

• Consider grouping Programming_oM with "Disciplines namespaces"; consider renaming to something more discipline-y (e.g. Scripting_oM)

• Create a Library_oM and move there the Data, source from the Data_oM

• Move out as much stuff as possible from the Data_oM to appropriate oMs: Requests -> Analytical_oM, etc. (see if dependency chain can be respected)

EDIT: Updated the diagram to latest WIP and point around Reflection namespace in light of updated diagram