Pipeline doc
This PR adds documentation to the pipelines and slightly modifies their behavior:

- `modelcard` is no longer available when using the `pipeline` factory method. As discussed with @thomwolf and @mfuntowicz, it doesn't serve any purpose for the user.
- All task-specific pipelines can now be instantiated without any model/tokenizer, instead relying on the defaults defined for the `pipeline` factory method.
Hmm, why do we want to be able to spawn a `NerPipeline` or a `QuestionAnsweringPipeline` without a model or a tokenizer?

Isn't this what `pipeline("ner")` or `pipeline("question-answering")` is for?<|||||>I think the question is rather why can't we spawn a `NerPipeline` or a `QuestionAnsweringPipeline` even though we have defined defaults for them?

What I see in the `pipeline` factory is the ability to simply specify a task and get the appropriate pipeline. I don't see a strong reason for the task-specific pipelines to not be able to load a default, but I may be missing part of the picture.

If you think this is unnecessary I can revert the code - we'll just need to make sure that the doc explains what the `pipeline` factory is for and how it handles defaults compared to task-specific pipelines, because I was misled.<|||||>I'll let @mfuntowicz and @thomwolf chime in, but for me, the subclasses of Pipeline are the actual implementations – preferably well-typed – that do not expose too much magic. 

I don't see the point of having two public APIs that do exactly the same thing.

E.g., the logic behind [get_defaults](https://github.com/huggingface/transformers/pull/3055/files#diff-1e87b75d7b313550a38be1daecd653f7R485-R504) is a duplication of what's already in `pipeline()`

In any cases, the subclasses of Pipeline dont accept a model/tokenizer of type `str`, in contradiction to the doc (it crashes), because the spawning of model/tokenizer with `from_pretrained()` is only inside the `pipeline` wrapper <|||||>Ok, this makes sense. I'll revert that later today. Thanks @julien-c