Add an API to update Crash Reports from the previous run of the app

[samedson]

• This adds an API to annotate and read data from the last Crash Report if there are any custom errors or a crash in it.

Changes

Background on Processed and Prepared Reports

• "processed" reports are ones that have been cleared for upload and have started to undergo on-device symbolication.
• "prepared" reports have finished on-device symbolication. In the past this location was where reports sat while they waited for upload. Now that GoogleDataTransport exists, reports exist in the "prepared" folder for only a split second before they are converted to GDT's format and handed off to the GDT SDK to manage.

Semantics Changes

The semantics should match the existing checkForUnsentReports, except this PR makes a change to how "processed" and "prepared" reports are handled with unsent reports.

Semantics Change:

• Before, if a crash was in "processed" or "prepared", but wasn't uploaded, it was considered unsent, and calling checkForUnsentReports would return true.
• Now, processed and prepared reports are not considered unsent, and reports in those directories won't cause the unsent bool to be true. With the new API, this will result in the CrashlyticsReport being nil (the same as there not being unsent reports).

This change should be ok because:

• Reports will only become processed or prepared when the developer has enabled automatic collection or called sendUnsentReports. Therefore, reports in these states are already considered "sent".
• Now that Crashlytics uses GoogleDataTransport, reports do not naturally sit in prepared or processed folders unless there is a problem. Before GDT, "prepared" reports were the ones Crashlytics was waiting to upload. Now GDT manages reports waiting for upload.

The only theoretical tradeoff is what happens when a report becomes prepared or processed, but the app crashes or closes before the processed report is handed off to GDT. I'm calling these reports "In limbo".

• Before SDK will always report there are unsent reports if any reports are stuck in "limbo", but at least the developer knows. There isn't anything the developer can do to resolve this situation, and it could impact the end user if checkForUnsentReports is used to show a crash feedback dialog.
• Now the report won't be reported in checkForUnsentReports, but will need data collection enabled / sendUnsentReports to be sent.

[elenadoty]

What was the reasoning for this not being on a background queue?

[samedson]

We humaned on this - might move to a background thread if possible