Move All Code Used Exclusively by Generated Code to Rocks.Support

[JasonBock]

Describe the solution you'd like

Since Rocks became a SG, I've made the NuGet package in such a way that I essentially copy the Rocks.dll twice in the package. Basically, whatever I do allows a developer to reference Rocks itself so it can use types directly within Rocks. This makes it easier for me because I can get all the benefits of compiling that code, unit testing it, etc. However, this also means I have 2 copies of that assembly in the package. Furthermore, emitting more code when the SG starts up isn't ideal because that code is a string, and I have to wait until the tests compile (or run) to know if it works or not. Also, this could run into naming collisions that would not be ideal to resolve manually.

It would be easier to have this code in another assembly, called Rocks.Support. See this project file to see how to make this work.

Here's a list of types I think could move to this new project:

• RefStructArgument
• ExpectationException
• RockAttribute
• All of the types in the Polyfills folder
• Expectations
• Handler
• And others that I haven't identified yet...

This may end up being a lot of work, and I'd have to be careful and ensure that this supporting assembly is truly isolated from Rocks itself. This may also have the effect of moving almost all of the code currently in Rocks to this assembly. It's hard to tell right now. But, I think this is the right way to go, because that can target .NET 9, it can have its' own test assembly, and we can (fairly) easily deploy it with the Rocks NuGet package and do things "right".

Describe alternatives you've considered
Keep things as-is.