feat: Memory limited merge join

[korowa]

Which issue does this PR close?

Closes #5220.

Rationale for this change

Control over memory allocation in SortMergeJoinExec

What changes are included in this PR?

• SMJStream.reservation -- memory reservation to control buffered data size -- it may require significant amount of memory, for example, in case of multiple batches with the same join key values
• peak_memory_used -- during join execution, normally, both try_grow and shrink methods are called -- on adding new buffered batches and on flushing them if join key has changed, respectively. In this case it seems reasonable to track only peak memory for each partition -- after that it's summed up across all partitions which is not really precise, but still valuable in terms of showing "worst case" (in fact peak memory used, probably, can be lower)
• memory limit tests now are able to run with configurable SessionConfig and perform multiple checks on returned error (used to ensure that memory allocation failed in specific operator/stream)

Are these changes tested?

• existsing test cases (shrinks don't lead to negative size)
• overallocation tests for all join types (if accepted by merge join operator)
• SQL-level test for overallocation

Are there any user-facing changes?

SortMergeJoinExec should now respect runtime memory limitations.

[alamb]

Thank you @korowa -- this looks great. I reviewed the code and made sure the reservation was updated when the buffered batch was pushed/poped.

cc @richox who I believe contributed the original implementation in #2242

[alamb]

Thank you for the unit test

[Dandandan]

Suggested change

	+ 24;
	+ sizeof::<Range>()
	+ sizeof::<usize>();

[korowa]

True, it may vary. I've fixed it in separate commit, thank you!