Code Separation (Step Three)

SCSF was fully removed from NaroCAD codebase. This may not sound much, but will likely simplify a lot of codebase interactions.
Some may ask why SCSF was used in first place, and why was removed? SCSF is a a framework that makes easy to solve use-cases. Even the specifics may be fairly hard to describe just in some lines, an use-case was an instance that activates in cascade other use-cases defined as a dependency and so on. Also it have a powerful dependency injection mechanism and also modules, that they behave as plugins.
SCSF is fairly complex, as the big is its featureset. This maked that usage in NaroCAD to be used as message passing framework, but to send a message, in most instances was sent a message globally (to the root of use-cases) and was hard to get an overview. Another issue with it was that integration with anything else was fairly hard. Even the events (the message passing) was done with adnotations, at the end, the code were translated eventually in NaroCAD actions.
Why NaroCAD have actions instead of using SCSF use-cases? Because SCSF was harder to track and debug and also it's dependency solving of the things that were needed was not that trivial. As the codebase was done, mostly the person that wanted to add for example a circle, started with OpenCascade code, tried to add it to OpenCascade view, and after this the code was separated and refactored to an unit named action. As an action was depending for mouse for example, the code was a big mix in the SCSF's controller class to make that action to get that mouse.
So NaroCAD Actions evolved to use pipes and filters and an pipes "solver" that will give the requested dependencies to that action. This gives for developper a bottom-up view, which is easier to aproach as you don't have to dwelve in the NaroCAD framework too deep: you copy/paste an action and its registering code and you're ready to go. Also this maked possible to add unit testing to them.
What about the plugins? The plugins of SCSF were nice, but the perceived advantages were really hard to setup in practice, as we would have to create an Xml parser and editor and insert nodes at specific points in the "ProfileCatalog.xml". Even this was done, with testing and bug fixing would take longer than setting up an auto_plugin.naro file where anyone can simply add plugins dinamically with much less tooling. Another good thing is that you mostly don't have to understand two conventions: SCSF ones and NaroCAD ones.
Pipes&Filters (as the internal NaroCAD actions framework behavior) are known to solve complexi problems even with multiple foreign frameworks and some of the most known are multimedia frameworks as DirectShow (or GStreamer) but also to launch custom eterogene tools: the Unix shells.
Today I've made that behavior to match the previos behavior and also I've removed all SCSF related libraries. You as an user may notice that future installations will be a bit smaller and also NaroCAD will start (a bit, but visible) faster as will not load and make some scanning of modules for attributes as SCSF did.
One last note: SCSF is really powerful, the problem is that from complex codebases, with virtually no design architect or a similar position, is fairly hard to be mapped as a top/down design, because most of the coding in specific tools is setup down.