Initial implementation of ReplacementVisitor

[AnyOldName3]

Pull Request Template

Description

As discussed on a call last year, and alluded to in some PR/issue/discussion comments since, a vsg::Visitor can't replace objects in the scenegraph it operates on except by handling it at the level of their parent. If you know the structure of the data being operated on and either the object only makes sense in the context of its parent (e.g. swapping the vertex buffer of a VertexIndexDraw) or can limit the number of parent types to a feasible number (e.g. you know the node you want to swap out will always have a StateGroup as its parent), that's fine, but that's not always the case with real-world data.

An example use-case is the IntersectionOptimizeVisitor on my intersection optimisation branch that swaps out nodes for an optimised class which handles intersections faster (and passes other kinds of traversal onto the original node). At the moment, it explicitly handles StateGroup because that's the parent of the target nodes in the sample data I've got, but to work in the general case, it would need to explicitly handle every VSG node type that can have one or more children. With this PR applied, it can just handle the specific node types it targets and avoid needing to handle every possible parent. It would also make it easier to move the generated intersection proxy nodes higher in the scenegraph when only one node in a subgraph is intersectable.

I've implemented a slightly contrived but more obvious and straightforward example for the vsgExamples repo that illustrates how the new visitor type can be used and points out a gotcha I expect users of the class might run into. The PR for that is here: vsg-dev/vsgExamples#392

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

So far, basically just the new vsgExample I made to demo the feature. I've not yet adapted the intersection optimisation branch to use it, as I thought it was a good idea to get more eyes on the implementation before marrying anything to it.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules