Remove Breakout prefix from classes where its redundant

[jonnew]

• Preserve backwards compatibility with old workflows.
• This commit requires a major revision increment Because we are in the 0 major revision, this change is permitted, even though its API breaking
• Fixes Remove Breakout from names of static hardware definition classes within Configure<> classes #297
• Fixes Change BreakoutAnalogInput to AnalogInput #300
• After this is merged, I will create 1.0.0 issue requesting the removal of obsolete types

[bparks13]

I see no issues with this PR. There are some missing XML comments from the newly created obsolete classes, but those are easy to fix.

Visually, if someone opens up an existing workflow that has one of these obsolete nodes, it shows the correct color but appears with cross-hatches to indicate that something is up.

It still builds correctly, shows the correct output types, and does not appear to throw any errors.

[jonnew]

Thanks for the review. The big issue we need to consider is do we put effort into maintaining backwards compatibility when we are in version 0.X.X? Im in the middle of refactoring the Bno055 to create a common class for all headstages that perform polling. Should I add these obsolete derived classes there as well? I guess so?

[bparks13]

I guess the question for BNO is what is the opportunity cost for adding the obsolete derived classes? I'm guessing there aren't many workflows that depend on this yet, but I think it would be good to add the derived classes if it is easy to do, and then remove the obsolete classes once we reach 1.0

[jonnew]

That's precisely what I was thinking as well. I will add them to the refactored Bno stuff. I also realized you can put a note in the [Obsolete] attribute. We will state there they will be removed in 1.0.0