hash join: add build-side join keys to memory accounting

[korowa]

Which issue does this PR close?

Follow-up on #14131

Rationale for this change

Having precalculated build-side join keys in JoinLeftData may be a noticeable overhead in terms of memory (always has been, but previously it's been recreated on each hashtable lookup), so it makes sense to add its memory into build-side data memory reservation.

What changes are included in this PR?

• Build-side join keys memory is now accounted in memory reservation. These keys are now collected from build-side batches iterator to increase reserved memory size gradually (in order to reduce the risk of getting OOM killed), and concatenated later
• Also due to arrow concat being non-consuming (and, thus, creating a copy of input data), concat operations for build-side join keys and record batches are now preceded by doubling up memory reservation for source data (trying to predict concatenated copy size), and followed by explicit drop of source data and resizing reservation to actual memory size of concat result.

Are these changes tested?

Existing test coverage, checking that build-side join keys evaluation not messed up.

Are there any user-facing changes?

No

[korowa]

cc @lewiszlw

[github-actions]

Thank you for your contribution. Unfortunately, this pull request is stale because it has been open 60 days with no activity. Please remove the stale label or comment or this will be closed in 7 days.