feat: consolidate custom error handlers

Today, bolt allows for two different kinds of error handlers to be defined in an app:

• there's an App constructor option called extendedErrorHandler, and when an error is bubbled up within bolt, depending on the value of this option, different behaviour is triggered for the user-provided error handler
• a whole set of types exist to support this distinction
• tests exercising this distinction need to use type casting liberally, since with this current API there is no TypeScript-aware overload that could be used for this current system to allow for narrowing the error handler type accordingly

Additionally, this distinction is not documented in our main docs about error handling: https://slack.dev/bolt-js/concepts/error-handling - so the two different kinds of error handlers is a semi-secret. However, it is part of the public API.

I suggest consolidating this: all error handlers are extended error handlers, so any defined error handlers have available to them all the arguments of an extended error handler. A 'simple' error handler can choose not to use the extended error handler properties (and only read from the error object itself).

I think it simplifies the code and API surface area.

Start with the linked sections in src/App.ts, especially the error-handler types, constructor option, bubbling behavior, and overload area. Review the related cases in src/App-built-in-middleware.spec.ts and the error-handling documentation to understand the current distinction. Done should include the consolidated public API, updated tests without the current type-casting pattern, and documentation covering the resulting behavior.