Upload Work Manager - API refactoring

[anchita-g]

          Discussed this with @anchita-g. One alternative way of handling this is to make the `UploadWorkManager` a little more stateful, similar to the `DownloadWorkManager`. In that case, there would be an API to feed local changes to the `UploadWorkManager`, there will be an API to pull next upload request to be sent to the FHIR server, and there'll be an API to get the sync status - almost like an iterator with a sync progress.

That would make the job of Uploader a little simpler - the while loop currently in UplaoderImpl would be simplified (because the work is done by the UploadWorkManager. This affords the developers a little more control - but admittedly we're not entirely sure if the additional contronl is urgently needed by the developers.

But that would make the design more alinged with the download workflow which @omarismail94 worked on.

FYI @aditya-07 as well.

Originally posted by @jingtang10 in #2022 (comment)