[FR]: [Crashlytics] Distinguish between cases of Swift enums used as non-fatal errors

### Context
1. Crashlytics reports non-fatal errors using their `NSError` representations’ `domain` and `code` properties.
2. When an `Error`-conforming Swift enum is bridged to `NSError`, each of its cases implicitly receives an error code. The order of declaration doesn’t guarantee consistency in code assignment.
3. When such an error is reported to Crashlytics, the Firebase console only shows the `nserror-domain` and `nserror-code` keys, which makes it impossible to identify the error deterministically (again, because error cases don’t have stable codes).
4. If the enum declaration is later modified (cases are added, reordered, or deleted), error grouping in the Firebase console usually breaks.

### Proposal
Introduce a way to uniquely establish and report the error’s identity based on the available info:
* For enums (which have stable case names but unstable error codes), each case should be treated as a separate error; ignore different associated values of the same case;
* For other types conforming to `Error`, use the `code` property from the bridged `NSError` (if the type doesn’t specify error codes via `CustomNSError`, the value defaults to 1);
* For real `NSError` objects (created [like this](https://developer.apple.com/documentation/foundation/nserror/errorwithdomain:code:userinfo:?language=objc)), use their instance properties `domain` and `code`.

### Alternatives
1. Do nothing—leave it the client’s problem (as it currently is). When you declare an error enum, it’s possible to conform it to Foundation’s [`LocalizedError`](https://developer.apple.com/documentation/foundation/localizederror) (to provide a human-readable description to distinguish between cases) or [`CustomNSError`](https://developer.apple.com/documentation/foundation/customnserror) (to provide actual error domain and code). This approach doubles the enum in size. It also requires changes in multiple places if the enum declaration is modified later.

### API Proposal

* No changes in the public API;
* To contain the scope, the identity info can be appended to the `userInfo` dictionary at the time of reporting.

### Firebase Product(s)

Crashlytics