Stitching Upload Components to support multiple Upload Strategies

[anchita-g]

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).

One of the PRs to fix #760

Description
We connect the four components: LocalChangeFetcher, PatchGenerator , RequestGenerator and ResourceConsolidator for upload sync to work according to any type of UploadStrategy provided.

Since we have not implemented al the types of the components, with the implementations we have so far, we can only use a few UploadStrategy.
The connection of the components is mainly established by maintaining a mapping of the LocalChanges to the respective outputs in each stage. For example, PatchGenerator is expected to output Patch as well as the respective list of LocalChange from which each Patch was generated.

For RequestGenerator, using the mapped Patch for LocalChanges, the request generator should output the UploadRequest generated as well as the LocalChanges of the Patches from which this request was generated.
For BundleRequestGenerator, the mapping to the LocalChanges is at the level of each entry in the BundleRequest.

This would help in the ResourceConsolidator where in each BundleEntry is like an independent request being executed with its own corresponding response, hence, we would need to know the LocalChanges which result in that particular BundleEntry request.

Alternative(s) considered
NA

Type
Choose one: Feature
Screenshots (if applicable)

Checklist

• I have read and acknowledged the Code of conduct.
• I have read the Contributing page.
• I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
• I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
• I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
• I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
• I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).