WIP: Switch batches to new serialization traits

[Lorak-mmk]

Pre-review checklist

This is still a work in progress - some tests are still not adapted.
The approach I took is the one we discussed - of making Batch a builder that serializes query parameters as user adds them.

At first I thought about gradully serializing the whole batch into one buffer, but there are many places that require iterating trough batch's contents - which would not be possible then. So now I'm serializing query parameters into SerializedValues, and only Batch in scylla-cql puts everything togother into one buffer.
The downside is that each call to append_statement performs an allocation - but that was already the case with the previous interface used BatchValuesIterator::write_next_to_request which internally uses ValueList::serialized which performs an allocation.
The downsides in current interface compared to previous one are:

• Now we need to materialize all queries and values, and then copy them to final buffer - so it probably uses more memory than previous API (How much more - I don't know, not more than 2x).
• append_statement may return SerializationError - because it creates SerializedValues from provided SerializeRow immediately.
• Query variant doesn't take values - we can't prepare it as there is no Session available. I'm thinking about changing the interface a bit and fixing this, it shouldn't complicate the interface too much - but first I'd like to know if that is something we want, or are we going in the direction of disallowing values in simple queries at all (in APIs like Session::query*).
  The upside is that it is much easier to understand - there isn't a ton of weird structs and traits like in value.rs.

I considered (and tried to implement) some alternative solutions

1. Interface pretty much identical to the old one.
   First idea was to copy the previous interface, change ValueList to SerializeRow, add PreparedMetadata argument to BatchValuesIterator methods, and adjust the rest of the code.
   The problem is that Batch in scylla-cql doesn't store PreparedMetadata. I could add it to it's BatchStatement enum, but then we couldn't deserialize it - as the serialized for doesn't contain the metadata.
   There would also be a question on how to handle Queries (as they wouldn't have values) - store empty SerializedValues in the iterator? Store None? Skip it, which makes statements list and values list different in length? I don't see elegant answer.

2. Similar interface, but containing not values, but statement-value pairs.
   The idea is to create BatchStatement trait with write_to_request method. Rename BatchValues to BatchStatements and provide similar methods to the ones currently present in BatchValues.
   scylla crate would implement BatchStatement for it's version which would be generic and contain a reference (or Cow) to SerializeRow, and scylla-cql would implement it's own version, with SerializedValues.
   This version doesn't add PreparedMetadata argument to methods, as the iterator values contain a query or statement-values pair, so the values can be serialized using proper statement. This would also remove the possibility of statement list and values list having different lengths.
   The problem is that Session::Batch and a lot of other code needs to inspect the statements - so they can't be hidden. This is the case in prepare_batch and in calculating the token of first statement in batch.
   I considered adding a calculate_token method to BatchStatement trait, but it seems like an ugly hack, and there are other places in code code that inspect the queries.

There are other solutions which I considered / tried but I don't remember them now - in many the problem is the layering (scylla vs scylla-cql, scylla-cql not having access to scylla types) - imo this layering is a good design, but it doesn't make this particular task easier :D

TODO:

• Fix broken tests
• Proper commit message

• I have split my patch into logically separate commits.
• All commit messages clearly explain what they change and why.
• I added relevant tests for new features and bug fixes.
• All commits compile, pass static checks and pass test.
• PR description sums up the changes and reasons why they should be introduced.
• I have provided docstrings for the public items that I want to introduce.
• I have adjusted the documentation in ./docs/source/.
• I added appropriate Fixes: annotations to PR description.

[Lorak-mmk]

Closing as it was succeeded by #881