Type annotation for `pipeline()`s
### Feature request

Currently, the return type of many functions are not defined.
```py
tokenizer = AutoTokenizer.from_pretrained("distilbert-base-uncased-finetuned-sst-2-english")
tokenizer( # no type checking/help here
```

It would be nice if the return type was set, the equivalent of me doing it manually with:
```py
tokenizer: DistilBertTokenizerFast = AutoTokenizer.from_pretrained("distilbert-base-uncased-finetuned-sst-2-english")
tokenizer( # now I get checking
```

### Motivation

The main benefits are probably pretty well understood...
* preventing typos in inputs that take strings (tasks, checkpoints, etc)
* autocomplete for methods/parameters in IDEs
* documentation tooltips in IDEs that support them.

### Your contribution

As you may already be aware, the pattern for enabling this is to use `Literal` and `@overload` from the `typing` module, to return a particular class based on the value of a string passed in.

A quick mock up:
```py
from typing import overload, Literal

class Model1:
    def model_1_thing(self):
        pass


class Model2:
    def model_2_thing(self):
        pass


@overload
def get_pipe(model: Literal["model_1"]) -> Model1:
    pass


@overload
def get_pipe(model: Literal["model_2"]) -> Model2:
    pass


def get_pipe(model):
    if model == "model_1":
        return Model1()
    return Model2()


mod = get_pipe("model_1")
# `mod` is correctly identified as an instance of `Model1`
```

Now I not only get auto-complete when typing in the string:
![image](https://user-images.githubusercontent.com/4443482/199659651-f3203eae-4034-48f3-bb15-6af44f833116.png)

But of course get the usual goodies when accessing attributes of the returned object:
![image](https://user-images.githubusercontent.com/4443482/199659741-da90c4f0-4459-411e-872d-93581c64d32d.png)

To support older Python, I think [typing-extensions](https://pypi.org/project/typing-extensions/) would work, although I'm not certain.

The big question of course is whether the "developer experience" gains are worth the effort/complexity this would add to the codebase.

Apologies if this has already been discussed and decided on, I couldn't see an existing issue, but did sense a willingness to get types right from other issues.
Thanks for opening the issue. As of now, we have decided not to add any type annotations that render the code less readable. So whenever they can be added with no cost in readability, we welcome PRs, but for something more complex like you are suggesting, we would probably be less interested.<|||||>That seems reasonable :)

For completeness, I'll note that the `@overload`s can go in a separate `.pyi` file, leaving the main application logic clean. But the complexity would still be there, and you'd have `.pyi` files everywhere, so this is not a great solution.