Add value block abstraction

[dain]

Description

This PR adds the ValueBlock interface to the SPI. A value block is a type of Block that contains actual values as opposed to the synthetic wrapper blocks DictionaryBlock, RunLengthEncodedBlock, and LaxyBlock. Each Type now declares the ValueBlock class used to represent the type. When interacting with data for a type, and implementation can safely cast a ValueBlock instance to the Types declared ValueBlockclass.

Additionally, there is a new VALUE_BLOCK_POSITION (and related VALUE_BLOCK_POSITION_NOT_NULL) calling convention that will ensure that synthetic blocks are unwrapped on the caller's side. This call convention is preferred as it empowers the caller to unwrap blocks outside of the core computation loop.

All aggregation functions have been updated to use ValueBlocks with the synthetic blocks unwrapped outside of the core loop. This change does require that each aggregation parameter have a separate position instead of a shared position as the unwrapped blocks can be unaligned.

This is part of #14237

Fixes #13267

Release notes

(X) Release notes are required, with the following suggested text:

# Section
* Add `ValueBlock` abstraction along with `VALUE_BLOCK_POSITION` and `VALUE_BLOCK_POSITION_NOT_NULL` calling convention. ({issue}`19385`)
* Aggregation functions now require a separate block position for each argument.  ({issue}`19385`)

[electrum]

Would it make sense for this to be

public interface ValueBlock<T extends ValueBlock>

Then the methods would be

@Override
T copyPositions(...)

This would require implementations to override all of the methods with the correct return type.

[dain]

Generally, I don't like making these interfaces generic as they aren't used in ways that the generic type would help.... basically all uses would be Value<?> or even worse Value<? extends Value>. I think we can satisfy this by adding a test that verifies no methods on an implementation return ValueBlock (so they are forced to override the return)

[electrum]

We could add a byte array equals method to Slice

[dain]

yep... we could also go the other way and unwarp here. For now, this follows the style of the other operators.

[electrum]

Do we need this version? Or can the engine invert the above?

[dain]

It could, but the conversion code isn't that bright right now.

[electrum]

Why don't all of these method additions need revapi changes? Maybe it doesn't flag on new methods?

[dain]

We only check for backwards incompatible changes

[dain]

/test-with-secrets sha=e872b5c29db025e8673099ff64f4f25e6d2b8aee

[github-actions]

The CI workflow run with tests that require additional secrets finished as failure: https://github.com/trinodb/trino/actions/runs/6583554942