.tsv-based reflection mechanism migrated to BHoM_Engine

[pawelbaran]

NOTE: Depends on

BHoM/BHoM#1724
BHoM/BHoM_Engine#3596

Issues addressed by this PR

Closes #563

Recommended review process:

The PR is a byproduct of my investigation of the topic as explained in #563. It is not fully finished, there was quite a few copy-paste actions, todos left etc., so more work required, but the intent is hopefully clear. The code works (.tsv processing, loading scripts, RunExtensionMethod, dynamic assembly load), the only feature that does not fully work is ctrl+shift+b due to the fact that ItemByKey method is not fully finished.

Recommended sequence to review, with key points mentioned:

1. Migrated oM objects to BHoM:
   • put in Base_oM\Reflection, but this is a placeholder, happy to move somewhere else
   • Json prop removed from CodeElementRecord class
   • CodeElementType enum items changed to be more focused on actual reflection
2. Migrated the code from BHoM_UI to BHoM_Engine:
   • AssemblyResolver class moved to BHoM_Engine\Objects (code unchanged)
   • most of the code was put in BH.Engine.Base.Objects.Initialisation - please treat it as a placeholder, I put it together under one class to make it easier to review - main changes compared to the original BHoM_UI code are around input parameters
   • Query.CodeElements method and its dependencies migrated to Reflection_Engine because it depends on methods from that project - the method itself has been simplified to align with the new version of CodeElementType enum, also try/catches added etc.
   • new addition: BH.Engine.Base.Query.ItemByKey method that allows to find a member based on a key (the key is the same or almost the same as keys used in versioning), to replace JSON deserialisation - the method is not finished yet, just proves the concept by reflecting types and non-Create methods
3. BHoM_UI:
   • lots of files deleted altogether (most migrated to BH.Engine.Base.Objects.Initialisation and Reflection_Engine in untouched state)
   • BH.UI.Base.Global.Initialisation class refactored heavily: many methods moved out to BH.Engine.Base.Objects.Initialisation and made more parametric, what is important is that the flow of Activate method stayed untouched
   • SearchItem, SearchMenu, ItemSelectorMenu aligned with the new oM (no Json property, changed enum)
4. Revit_Toolkit - Initialisation class leveraging the changes listed in points 1. to 3.:
   • no dependency on BHoM_UI
   • combine CodeElementRecords from the base .tsv with a dedicated set and .tsv - possible thanks to more parametric design of the code

Testing

For now I would not obsess about functionality, because code principles are more relevant. However, if you'd like to verify the concept overall, then follow this sequence:

1. Compile the PRs (remember about Grasshopper_UI!)
2. Remove AssemblyContents.tsv file from BHoM\Resources folder (schema changed) - for now this step is required, but if we decide to merge this PR, we'll need to change the default .tsv path to protect the users
3. Open GH, check if AssemblyContents.tsv is being created
4. Restart GH, check if the .tsv file is picked up
5. Open an existing Grasshopper script and see if everything is OK
6. Try running RunExtensionMethod (e.g. by passing a line and Length as method name)

Changelog

Additional comments

Consolidation of CodeElementType enum could go even further, so that methods from all 5 classes would land under 1 value, for the UIs to dispatch them at runtime - this, however, would mean that we'd need to query strings every time the information about declaring type is needed. I did not dare to do it in the 1st iteration, but still on my hitlist to try and see how it lands.