Tracking Issue: Cleanup Blueprint and Collection Diffs

[andrewjstone]

We currently use omdb to output blueprint diffs. This is an enormously important feature and we use it all the time. However, the code used to implement these diffs is gnarly and tedious. The primary reason for this is that we also generate diffs between blueprints and inventory collections and represent the output in the same way. Inventory collections lack a number of things present in blueprints, and yet we try to diff the 2 in a way that's useful for humans.

I seem to be the primary one continuously getting stuck here when adding reconfigurator features to blueprints, which I guess is fair, because I also refactored a bunch of the original code for generating diffs to make it easier to use. It may be slightly easier, but it still sucks. What we need to do is make the diff generation between blueprints and between blueprints and collections entirely different code paths, and have them generate different output. We want as much information as we can get in these diffs and we also want to make it easy to go back and add more.

Currently, we don't actually use the diffs between blueprints and collections anywhere, and so I'm starting on this immediately because I need diff changes to finish my implementation to resolve #6999 and #7098. I don't wan to go through the same tortuous process I went through in #6968. I assure you that you will also not want to do this.

The steps I'm proposing - loosely ordered after the first are:

• Remove all code that diffs collections and blueprints. This will substantially simplify the path, but not make it super easy to add new code.
• Add support for diffus to blueprints
• Add Visitor trait for traversing blueprints
• Implement Visitor for outputting Diffs and use it
• Implement Visitors for test usage instead of BlueprintDiff and delete legacy BlueprintDiff code
• Re-introduce code to convert blueprints and collections into a common type with only fields common between them.
• Create a Visitor for for the common type
• Implement Visitor for table output and use it

This will get us to a much better place and help maintain sanity.