value: Cql[Varint/Decimal]Borrowed

[muzarski]

This PR introduces borrowed versions of CqlDecimal and CqlVarint. It implements SerializeValue and DeserializeValue for new types.

There is a use case for this in cpp-rust-driver - we need to set the pointer user provided, so it points to the underlying data. After lazy-deserialization refactor in cpp-rust-driver, CqlDecimal is not useful anymore. If we deserialize to CqlDecimal, it owns the bytes and is a stack variable - thus, we cannot set the pointer to its underlying data (it will be freed after function call).

Questions for reviewers:

• Should I put it under #[cfg(cpp_rust_unstable]? I think it may be useful for other users as well.
• I only implemente From<Cql[Varint/Decimal]Borrowed> for Big[Int/Decimal]. I didn't implement conversions in other direction, since new types borrow bytes (and From consumes). Do you think it's ok to make an exception here, and implement From<&Big[Int/Decimal]> (from reference)?

Pre-review checklist

• 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.

[github-actions]

cargo semver-checks found no API-breaking changes in this PR! 🎉🥳
Checked commit: 5808f5a

[Lorak-mmk]

Now that I think of it: can we just use Bytes for CqlVarint?

The only downside I see is that it would make the whole frame alive as long as CqlVarint is alive, but it is also the case for CqlVarintBorrowed (as it borrows the frame) - the only difference is that the latter is enforced at compile time, but complicates the code.

This is a tradeoff, and I'm not sure which solution is better.

[muzarski]

Now that I think of it: can we just use Bytes for CqlVarint?

The only downside I see is that it would make the whole frame alive as long as CqlVarint is alive, but it is also the case for CqlVarintBorrowed (as it borrows the frame) - the only difference is that the latter is enforced at compile time, but complicates the code.

This is a tradeoff, and I'm not sure which solution is better.

I like this idea. This simplifies code by a lot.

[muzarski]

I applied @Lorak-mmk suggestion - replaced Vec<u8> with bytes::Bytes in CqlVarint.

[muzarski]

Reverted the changes with Bytes. After a discussion, we decided that CqlVarint should not keep whole frame alive (and this is what it does when it holds Bytes).