[Updater] Introduce a DependencyChangeBuilder class to complete encapsulation of diff generation

[brrygrdn]

We've started the process of isolating the main updater operations into concrete classes by extracting the codelines for:

• Creating fresh updates for all out of date dependencies
• Refreshing an existing PR for a single out of date dependency

Next we plan to do the same for Security update workflows, but before this we're focusing on removing duplicate code and extracting business objects to encapsulate some of the concerns. ( #6991, #6989 ).

This pull request completes the work we started a while back where we introduced a DependencyChange object which describes the outcome of an operation in terms of the dependencies that have been updated, the updated dependency files, the base SHA it was generated from, etc.

Until now this was just a value class which was used to simplify the interface with the Service/Client layer, but this Pull Request moves the abstraction further up into the shared logic of actually generating the changed files and filtering the dependencies we attempted to update to just the list that did update.

By consolidating this behaviour in a DependencyChangeBuilder, we can remove a significant amount of duplication.

[Nishnha]

Wouldn't we want to still filter out the deps here? updated_deps comes from the update checker, and not from the dependency_change_builder's updated dependency files

[brrygrdn]

We still do perform this filtering, it just happens inside the DependencyChangeBuilder now instead

[Nishnha]

Ah never mind, I thought we were duplicating work in the UpdateChecker since both compile_updates_for(dependency, dependency_files) and create_change_for(lead_dependency, updated_dependencies, dependency_files) call out to it.

I think it would make sense to let the DependencyChangeBuilder use the UpdateChecker to fetch updated_dependencies rather than having to pass them in separately in create_change_for

[brrygrdn]

Yeah, I've thought a bit about that but a lot of the operation-specific logic differs in terms of how the UpdateChecker is tested before we decide to proceed to actually creating a dependency change.

I think that will end up being the main source of logic that is different for each operation - but there might be a follow-up pass where we can have one class encapsulate most of the UpdateChecker invocation + common checks, then leave space for job-specific additional checks before going on to create the actual change.

[Nishnha]

This generally looks good to me. I think the smoke tests should be enough to verify that the DependencyChangeBuilder is working as intended