I was told "OK I see this error message but my struct already implements Selectable so that's not useful".

As it turns out, this message would sometimes be misunderstood as the `check_for_backend` part only relating to the `QueryableByName` usage, but not to the `Selectable` usage, whereas that is in fact the key point.

Hopefully this new writing will avoid this. :)

Co-authored-by: Georg Semmler <github@weiznich.de>

…ckend]`

Currently when a struct has `#[derive(Selectable)]`, `#[check_for_backend(...)]`, and `embed`s another `Selectable` struct that doesn't have `#[check_for_backend]` but whose `FromSqlRow` and `Selectable` impls don't match with regards to `CompatibleType`, the `#[check_for_backend]` does not point us to which of the embed fields is the culprit, because they are ignored.

It seems that this can be avoided by generating the checks even for `embed` fields.

The check for this was disabled in d6d9260 when the experimented-with approach was "always generating the check on Selectable" with the justification that it was consequently checked by the underlying field's own Selectable checks, before it was decided to instead have the `#[check_for_backend(...)]` attribute, so it seems that this justification was indeed legitimate at the time it was introduced, and doesn't hold anymore now.

This commit turns the `read_*` functions of the `SqliteValue` type into
public functions, which makes it easier for third party crates to access
the underlying sqlite values in a performant way. This enables crates to
not clone for example the string, but rather reuse the string slice we got
from sqlite instead.

This also turns all these functions into methods that require a mutable
reference instead of a shared reference as technically each of those
methods might mutate the underlying value according to the sqlite
documentation.

This commit relaxes a trait constraint that restricted our copy from
implementation for `Insertable` types to 12 columns. That happened
because we used the `Default` impl for tuples from the rust standard
library to construct the column types internally. The standard library
only provides these impl for up to 12 tuple elements. 

The fix is to simply construct that type by calling `Default` for each
of the column types seperatly and then constructing the tuple from that.

I choose to not write a test for that as it doesn't change functionality
in any meaningful way other than just allowing larger tuples.

This commit prepares a 2.2.8 release that includes the following
changes:

* #4472
* #4484
* #4486
* #4480

Remove trailing whitespace after ASC/DESC postfix operators

Add space in "DISTINCT ON (...) "

Remove unnecessary space from DELETE that causes duplication

This commit updates our locally used rust version to 1.85. This time
there were no new clippy lints

It also updates the compile test output to match the new compiler
output.

(cherry picked from commit 8bd9c98)

Conflicts:
	rust-toolchain

…te_types_doc