[FR]: provide a way to tell when recorded exceptions end up getting lost

### Description

1. When using `Crashlytics.crashlytics().record(error: error)`, it is clear from the documentation In [here](https://firebase.google.com/docs/crashlytics/customize-crash-reports?platform=ios#log-excepts) that Crashlytics does not provide any warranties of an exception being uploaded after recording:

* _Crashlytics only stores the most recent eight exceptions in a given app session. If your app throws more than eight exceptions in a session, older exceptions are lost._
* _Incorrect usage of the recordError method can cause unpredictable behavior and may cause Crashlytics to limit reporting of logged errors for your app_
* _Keep in mind that logging an NSError can be fairly expensive. At the time you make the call, Crashlytics captures the current thread’s call stack using a process called stack unwinding_
* _must limit the amount of space allocated for logs on disk, it is possible to log enough after an NSError is recorded so that all relevant logs are rotated out by the time Crashlytics sends the report from the device. Keep this balance in mind when logging NSErrors and using logs and custom keys in your app_

2. Currently, it is impossible for me to make a rough calculation of how many exceptions my application is recording that do not get uploaded

### API Proposal

Provide some way of:
* Knowing how many recorded exceptions are not being uploaded. I was looking at logs generated with `FIRDebugEnabled`, but I do not seem to be able to get any similar information, for example saying `uploaded 8 exceptions out of a total of 654 that were recorded in previous session`
* Returning something from the `record` function that tells:
* If the exception was recorded
* If the exception is going to be uploaded. I understand at the point of recording is not possible to tell if the exception will be uploaded, but you could tell for example if the current invocation of `record` is resulting in any other exception being lost, so developers are aware that by recording this exception, they are loosing other previously recorded exceptions
* Or maybe a bit extreme but 😄 if it is not possible for Firebase to provide some more visibility about which exceptions are being uploaded, maybe it makes sense to deprecate this feature. I can explain a bit more: having a reporting engine for exceptions that is not able to upload more than 8 exceptions creates false expectations to developers, that end up relying in the uploaded exceptions without realising that the amount of them is nowhere near the real recorded amount. Even if all developers in the team are aware of the limitations of the engine, I believe it is very easy to inadvertently record more than 8 exceptions as soon as an app and a developer team grows.

### Firebase Product(s)

Crashlytics