GH-51834: [C++] Reduce ARROW_ASSIGN_OR_RAISE stack consumption with gcc/clang

[taepper]

Rationale for this change

@pitrou found in investigations that repeated uses of ARROW_ASSIGN_OR_RAISE can lead to very large stack consumptions.

What changes are included in this PR?

This PR adds a new definition of the ARROW_ASSIGN_OR_RAISE macro, which avoids intermediate results using a gcc/clang compiler extension.

Are these changes tested?

No new feature, all tests still pass.

Are there any user-facing changes?

Yes. The ARROW_ASSIGN_OR_RAISE macro is a public interface and now has a breaking change:

If lhs is a declaration, it will already be in scope for the body of the right-hand-side. This lead to one breakage in the arrow code-base:

    ARROW_ASSIGN_OR_RAISE(auto options,
                          GetReadOptions(*reader->schema(), *self, *options));

which needed manual fixing. This could also break users of the C++ library

Was AI used for this PR?

In accordance to the AI generation guidelines, please disclose below whether and how AI was used in this PR.

PR code and description written by:

• Human
• AI

Reviewed before submission by:

• Human
• AI
• Not reviewed

• GitHub Issue: [C++] Excessive stack consumption with ARROW_ASSIGN_OR_RAISE #51834

[github-actions]

⚠️ GitHub issue #51834 has been automatically assigned in GitHub to PR creator.

[createcentury]

The gcc/clang specialization looks good to me.

I checked the two things this expansion could have quietly broken, and both come out clean:

• Shadowing. Moving lhs to the outside of the statement expression changes name
  lookup inside the initializer, which is what the file_ipc.cc rename is about. I went
  through the rest of cpp/src for the same pattern and that is the only site, so nothing
  else needs renaming.
• Lifetime. The intermediate Result now dies at the end of the statement rather than
  the enclosing scope. Nothing binds it by reference — there are no auto&& or auto& left
  hand sides — and the std::string_view ones view into storage owned elsewhere, so they're
  unaffected.

clang at -O0 stays where it was, as your table shows, but killing the growth in gcc -O0
and in both release builds covers most of the pain.