Implement PROVIDED_BLOCKBUILDER return place convention for scalar function

[wenleix]

Currently the only return place convention for scalar function is STACK, and the callee will append the results value on stack into the result BlockBuilder (for out-most function call) or use it to invoke other functions (for inner/nested function call like f(g(x))).

For functions returns Slice and Block, this return place convention usually result in copying the data twice -- once generate the data, once copy the data into the output BlockBuilder.

This commit implements PROVIDED_BLOCK return place convention to allow scalar function implementation choice to directly write to the desired place. Similar to the BLOCK_POSITION null convention, a implementation choice used default STACK return place convention must be implemented. Besides STACK return place convention, the developer of the scalar function can choose to provide an additional implementation choice with PROVIDED_BLOCK return place convention.

In the future, an invocation adapter should be able to automatically adapt between different calling conventions (null convention and return place convention) when feasible.

---

See more details in #9638

[dain]

Can you expand the description in the PR and the commit adding this feature?

[haozhun]

In the future, an invocation adapter should be able to automatically adapt between different null conventions and return place conventions.

I don't think there is value in having this be a full graph due to the performance hit it involves. As a result, to set the record straight, I would clarify that this will only be the case between certain convention pairs.

[haozhun]

"Introduce ReturnPlaceConvention for scalar function" - looks good

[haozhun]

"Add output block to RowExpressionCompiler.Context" - looks good

[haozhun]

"Support compiling RowExpression write to output block" - looks good

[haozhun]

"Implement PROVIDED_BLOCK return place convention" - looks good

Add explanations to the body of this commit. The PR description seems pretty reasonable.

This PR adds the basic feature. However, the example/test didn't attempt to dive into the complexity of handling error conditions during function execution. I think it's reasonable to leave that out of the PR. But this will need to be addressed before this feature becomes generally useful.