docs: [WIP] Update routing/request/response docs

[provinzkraut]

This is an attempt to clean up the docs for routing, route handlers, parameters, requests and responses.

The individual chapters and sections currently lack clear boundaries and mix up a lot of topics, so that a user has to go through all of them to gather the necessary information.

The goal here is to split the sections not only functionality wise but also between usage and reference documentation, where the usage documentation should be more task focused (i.e. "how do I do X?"), while the reference should focus on the functionality of the components (i.e. "this class has these methods", "this decorator can be configured like so").

---

This is a work in progress. I am currently mainly trying to establish an outline for a sensible structure.

[peterschutt]

A great start! I know still a WIP but a couple of comments you can take or leave. Thanks!

[peterschutt]

Suggested change

	Instances of :class:`~litestar.app.Litestar`, a special type of router that serves
	as the entry point of an application, in addition to receive the same configuration
	routers can
	Instances of :class:`~litestar.app.Litestar`, the entry point of an application, and a
	specialized type of router, so it can receive the same configuration as routers can

This wording was a bit awkward - not sure if my suggestion is much better though!

[peterschutt]

These are part of the
path string and follow the basic form of {<parameter name>:<parameter type>}, where
<parameter name> is the name of the parameter used to make its value available to
the route handler and what will be represented in the OpenAPI schema, and
<parameter type> a basic Python type that this parameter will be validated against
and, if possible, converted to.

This is quite a big sentence - might be better to break it up into smaller ideas, e.g., a sentence that introduces the two components of the parameter, then one explaining parameter name, and another to explain parameter type.