Introduce CCCL clang-format

[gevtushenko]

Description

closes #544

This PR introduces a CCCL-level clang-format file. There are a few minor differences compared to the original Thrust/CUB file.
We also temporarily specialize clang-format for libcu++ not to reorder includes.
Ideally, include order should not matter or at least all necessary places should be guarded with clang-format off/on. We prefer not waiting for all the fixes and get clang-format sooner. Once libcu++ include order issues are addressed, we can remove associated clang-format specialization.

Checklist

• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[miscco]

We should discuss this internally. I am personally not a fan of

BraceWrapping:
  AfterControlStatement: true
  BeforeCatch: true
  BeforeElse: true

It needlessly clutters the code as we have a lot of small conditionals in libcu++

    if (__other.__has_val_)
    {
      _LIBCUDACXX_CONSTRUCT_AT(this->__union_.__val_, __other.__union_.__val_);
    }
    else
    {
      _LIBCUDACXX_CONSTRUCT_AT(this->__union_.__unex_, __other.__union_.__unex_);
    }

vs

    if (__other.__has_val_) {
      _LIBCUDACXX_CONSTRUCT_AT(this->__union_.__val_, __other.__union_.__val_);
    } else {
      _LIBCUDACXX_CONSTRUCT_AT(this->__union_.__unex_, __other.__union_.__unex_);
    }

The former just introduces a lot of visual noise for libcu++. On the other hand @senior-zero has some valid points about larger conditionals in cub, so its not a hill I would die on

[gevtushenko]

@jrhemstad there's a consensus on merging this PR. One issue is that it requires clang-format 17, which we still don't have in our devcontainers. Current position is that the clang format file can be useful before devcontainers are updated because one can easily install clang-format-17 in our devcontainer and we do not force its usage for now. If you agree with this, please, merge the PR.