Rename Miscellany Classes to avoid conflict with Core Nodes

[thomascorrie]

Having the same class names as Core Nodes leads to warnings and clashes when using in DesignScript. Although it can be ignored it would be better have different names and use the Miscellany_DynamoCustomization.xml to categorize in the list

[thomascorrie]

Referred to this documentation for setting up a migrations file or node name changes: https://github.com/DynamoDS/Dynamo/wiki/Zero-Touch-Plugin-Development#migrations

[thomascorrie]

Others have changed their class names to plural to avoid this
DynamoDS/Dynamo#8981 (comment)
but if I change List to Lists then I get conflicts with others who have done this, e.g. Archi-Lab

I want to avoid MiscList or similar but that seems a robust way to avoid the problem

[thomascorrie]

I have tried various options and the least troublesome seems to be to rename classes to avoid conflict. In this first example I have focused on the geometry nodes. Instead of having a CoodinateSystem class I have amalgamated it into one Abstract class with methods named CoordinateSystemDisplay

Miscellany.Geometry.Abstract.CoordinateSystem.Display

becomes

Miscellany.Geometry.Abstract.CoordinateSystemDisplay

The downside is that the node goes from the simple name (and consistent with core Dynamo nodes) of CoordinateSystem.Display to Abstract.CoordinateSystemDisplay but I think that is the price that has to be paid to avoid class name conflicts and also names like CoordinateSystems.Display or MiscCoordinateSystem.Display

I have also added DynamoVisualProgramming.Core to the solution and used

[NodeCategory("Query")]

to reclassify those nodes from actions (⚡) to query (?)

Initial commit: 0872d64

[thomascorrie]

I have completed the review of class names with the following amendments.

CoordinateSystem > Abstract
Plane > Abstract
Vector > Abstract
Functions > Maths
List > Modifies

The slight lack of consistency in naming is unfortunate but it will avoid conflicts with core nodes or other packages until a proper solution is implemented in Dynamo itself

[thomascorrie]

Spoke to Keith Alfaro at the London Dynamo + Generative Design Hackathon 2019 and he confirmed that you need to avoid using the same class names