ErrorKit: Easy way to determine an "Error Call Stack"

[Jeehut]

Problem:

It is not always clear when an error is thrown in a lower-level function, what higher-level function calls caused running into this error situation. It's important to understand what screen or feature the users were using when they ran for example into a database-level error.

I think we need some kind of "error identification trace" here, e.g. with characters like in this suggestion:

1. We build a tool that can scan the source code of projects.
2. While scanning it detects all the errors conforming to Throwable and their cases (if they are enums).
3. While scanning it also detects all functions that use typed throws with their context type, name, and error type.
4. All error types get assigned a short unique ID (e.g. DFG), and all cases within an error also get a unique character (if less than 26 cases).
5. When developers are in a function that throws error type A, but call a function that can throw error type B, then this is also auto-detected by looking it up in the table.
6. In such a case, the tool automatically adds a nested case b(B) inside the A error type, because A could throw a B error if the inner function throws.
7. We could even provide a visual editor for error types and cases with an hierarchy overview that auto-generates all error cases from the app.
8. So users would end up having one Swift file that is auto-generated with all error cases and localized error messages (auto-localized in the app?).

@n0rthk1n9 What do you think? Sounds good? Sounds like too much? Did I even describe it well? 😅

[Jeehut]

Note that I found a much simpler solution in #22 than what was outlined above, which would have required a lot more work on our end (writing a Mac app) and also on the users end (setting up everything). This solution is much more practical and can be picked up by developers much more quickly. It's also less intrusive.