[WIP] Introduce UploadService to storage emulator

[tonyjhuang]

Description

Pulls all upload related logic out of StorageLayer into a separate UploadService. Updates the firebase.ts and gcloud.ts to use the new UploadService.

Other changes:

• Pulls Persistence into persistence.ts
• Injects Persistence into StorageLayer constructor since it's now shared with UploadService (and DI is just good practice)
• Migrates reset logic out of StorageLayer into StorageEmulator
• Pulls multipart request body parsing out into multipart.ts, refactors it to be more flexible, adds spec tests

[tohhsinpei]

I really like this, upload.ts is such a happy file. Left some minor comments. Also, you may need to rebase for some of the cancel logic, since I've merged #4210.

[tohhsinpei]

I would pass an Upload rather than its id here and have the caller worry about NotFoundError, similarly for finalise. I've floated this idea before... Thoughts?

[tonyjhuang]

I like the pattern, but I wasn't able to make it work for the following reason: since an Upload is essentially just a js object, any caller can construct arbitrary, non-db backed instances of it.

Ex:

# some bad caller or bug
public continueNonexistentUpload() {
  uploadService.continueResumableUpload({
    id: 'someNonexistentUploadId',
    status: ACTIVE
    ...
  });
}

public finalizeNonexistentUpload() {
  uploadService.finalizeResumableUpload({
    id: 'bogusValue',
    status: 'ACTIVE'
  });
}

Just because an Upload exists, doesn't mean that its registered in UploadService and unless UploadService assumes all Upload objects passed to it are valid, we still need to verify the state of the Upload in memory or else we run the risk of saving bogus data to our internal state.

[tonyjhuang]

Welp, this PR kind of got away from me and ended up being pretty large. This is in part due to the additional refactor of the multipart parsing logic.