updateRelatedChangeType perf improvements

[ecraig12345]

@derrickstolee's PR #1042 got me looking more closely at updateRelatedChangeType and its performance, which eventually made me notice that I'd accidentally introduced a (sometimes) massive amount of duplicate processing in that function in #606...

The problem is here: this function was always meant to process a single change info, but for some reason I updated it to process all changes from the same change file, which would then be repeated when the bumpInPlace loop runs for every other change from that file. This becomes a problem when a grouped change file has 3000 changes, and of course the graph traversal step is also running on that large graph...

The main change in this PR is removing the outer loop from updateRelatedChangeType, and updating it to bail out early if the change type is 'none'. (I also noticed a lot of other historical weirdness and bugs, but I'm just focusing on lower-risk fixes for now.)

Other smaller (non-test) changes:

• Remove redundant checks for change files referencing packages that don't exist (readChangeFiles already does that)
• Update initializePackageChangeTypes to ignore 'none' changes
• In getMaxChangeType, reduce the number of cases where getAllowedChangeType is called for disallowedChangeTypes

[derrickstolee]

Thanks for looking into performance improvements here!