Closes #2556

Notes:

• I did not add an ExtBotBuilder class. Currently only the request argument of ExtBot would profit from with. Then again, the init of ExtBot may become more complicated in the future if we add more features. If we want to add a corresponding class, we need to think about if we still want to allow for manual instantiation of ExtBot or not …
• I made sure that Updater can be used without Dispatcher. IMO this emphasizes that both have different tasks and for advanced users it may be helpful to outsource the fetching of updates while doing the processing manually.
• In the same spirit I made Dispatcher/Updater.exception_event properly documented attributes and they are no longer protected. While exception_event was probably initially meant as means for private communication between Updater and Dispatcher I do feel like it could be useful to have it more publically available for advaced, custom setups.
• I introduced a new type alias DefaultContextType = CallbackContext[ExtBot, Dict, Dict, Dict] . This made sence for the type hinting in the builders, but it seemed clever to me to make this also publically available to allow users to improve their type hints. DefaultContextType is the correct annotation if you're not using a custom ContextTypes object. The import of DefaultContextType can be fine tuned in the context of Clear up imports policy #2468
• Regarding type hints: At first I tried to make it so that already the type hints would indicate if e.g. builder.bot(bot) would fail because you already set a token. I quickly gave up on this because it became too excessive. Instead type hinting "only" covers job_queue, bot, persistence, context_types including bot/chat/user_data. This essentially makes sure that one can get proper type hints for all the attributes of the context argument. E.g. now it tells you if context.bot is tg.Bot or ExtBot and also if context.job_queue is None
• EDIT - More notes on type hints: set_dispatcher/updater_class don't have proper type hints, i.e. you won't know if updater or updater/context.dispatcher are instances of subclasses. IISC that's near impossible to get right and users that are so advanced that they want custom subclasses, should be able to handle that …

TODO:

• Add convenience methods Updare/Dispatcher.builder() -> Updater/DispatcherBuilder() and use those in the examples
• Fix test_dispatcher/test_less_than_one_worker_warning
• Update, if Rename private modules with leading underscore #2687 is merged first
• Check if I can up the coverage a bit more

Checklist for PRs

• Added .. versionadded:: version, .. versionchanged:: version or .. deprecated:: version to the docstrings for user facing changes (for methods/class descriptions, arguments and attributes)
• Created new or adapted existing unit tests