Fix how output and generic types are checked in the breaking change tool

[cormacpayne]

Description

Fix for #7151

Change how the breaking change tool validates output and generic type changes by checking more than just the name of the type.

Checklist

• I have read the Submitting Changes section of CONTRIBUTING.md
• The title of the PR is clear and informative
• The appropriate change log has been updated
• The PR does not introduce breaking changes
• If applicable, the changes made in the PR have proper test coverage
• For public API changes to cmdlets:
  • the changes have gone through a cmdlet design review
  • the cmdlet markdown files were generated using the platyPS module

[cormacpayne]

@markcowl @maddieclayton @MiYanni would someone mind reviewing this when they get the chance? 😀

[MiYanni]

Looks good... But, my boy, I needa teach you some good ol' data-driven design logic. Imperative logic is so old school. With the way this is built, you could likely make a map of predicates to values for checking most of the scenarios. Then, you'd likely only have one (or very few) calls to LogBreakingChangeIssue since you just inject the values needed for the call. It works similar to dependency injection. Either way, this PR is fineo for the mergeo. 🌮