Refactor and update docs

[alvarobartt]

Description

This PR refactors the documentation to make it more simpler and also to easily expose all the available Step, Task and LLM subclasses, as well as keeping everything simpler and more informative.

Not only the docs/ have been updated and re-structured, but also the docstrings across the whole codebase have been reviewed and updated, to include meaningful examples.

May eventually close #570, #613, #623, and #631

What's missing?

• Write docs/sections/components/advanced/routing.md from scratch @gabrielmbmb
• Write docs/features.md from scratch @gabrielmbmb

[alvarobartt]

The content is definitely improving but I had some general comments about the style of the docs, I've added some examples throughout. In general:

• I can't see a clear enough distinction for the 'components' section from the API reference.
• The docs often communicate from the perspective of the architecture, which the reader is unlikely to know. I think it would be easier to follow if they started by describing functionality, then gave an example, then describe the architecture if necessary. (within the components/learn section)

Thanks for the comments @burtenshaw, indeed the idea is to have the components explained there assuming that the developers may be interested on building their own distilabel pipelines, but yes, we are currently adding examples and more hands on stuff dedicated for the average user, but we'll take those things into consideration!

The idea now is to have an in detail reference on how to use any LLM, Step, or Task; but at the same time we'll be adding some guides on e.g. how to build your first pipeline and such, right under the Get started section in the docs (so above Components).

[ignacioct]

Enormous job, congrats! I've realised a first reading of the docs and pointed out some typos or grammatical corrections. Overall, I think sometimes the sentences tend to be very long and sometimes that can be difficult to read, so I've tried to correct that where I've seen it.

I'll do further corrections with the new changes.

[ignacioct]

Suggested change

	One can either extend any of the existing LLMs to override the default behaviour if needed, but also to define a new one from scratch, that could be potentially contributed to the `distilabel` codebase.
	If needed, the existing LLMs can be extended to override the default behavior, and new LLMs classes can be defined from scratch, which could later be contributed to the `distilabel` codebase.

[ignacioct]

Suggested change

	* `generate`: is a method that will take a list of prompts and return a list of generated texts. This method will be called by the [`Task`][distilabel.steps.tasks.Task] to generate the texts, so it's the most important method to define. This method will be implemented in the subclass of the [`LLM`][distilabel.llms.LLM] i.e. the synchronous LLM.
	* `generate`: is a method that will take a list of prompts and return a list of generated texts. This method will be called by the [`Task`][distilabel.steps.tasks.Task] to generate the texts, so it's the most important method to define. This method will be implemented in the subclass of the [`LLM`][distilabel.llms.LLM], i.e., the synchronous LLM.

[ignacioct]

Suggested change

	But `input_mappings` will only map, meaning that if you have a batch with the column `A` and you want to rename to `B`, you should use `input_mappings={"A": "B"}`, but that will only be applied to that specific [`Step`][distilabel.steps.base.Step] meaning that the next step in the pipeline will still have the column `A` instead of `B`.
	But `input_mappings` will only map, meaning that if you have a batch with the column `A` and you want to rename to `B`, you should use `input_mappings={"A": "B"}`, but that will only be applied to that specific [`Step`][distilabel.steps.base.Step]. This means that the next step in the pipeline will still have the column `A` instead of `B`.

[alvarobartt]

Thanks for the detailed review @ignacioct, we'll make sure to add that feedback! 👍🏻

[alvarobartt]

Hi here @ignacioct could you review this file again? Sorry for the inconvenience, apparently @plaguss merged the PR for the FAQ refactoring while you were reviewing so I couldn't apply your suggestions here, thanks again for the review!