[DOC]: Create a CCCL developer guide

[bernhardmgruber]

Developing CCCL involves a lot of conventions you have to be aware as a developer. Those conventions vary between different subprojects, but also a lot of commonalities (especially coming from libcu++) exist. It's hard to stay on top of everything, so I propose we should have and maintain a developer guide for our contributors and ourselves. This guide may be maintained in the CCCL repository or as a set of wiki pages.

We already have a CUB developer guide, which we link from CONTRIBUTING.md.

Issues asking for such a contributing/developer guide:

• [DOC]: Create libcudacxx Developer Guide #95
• Author contributor guide for consolidating Thrust/CUB kernels/algorithms #1585
• [DOC]: Document relevant CCCL macros #2504

Instructions on how to build and test CCCL, or using devcontainers, may be moved into this guide or at least referenced from it.

This documentation should be intended for CCCL contributors/developers only, not for users. As such, it should contain a big disclaimer, that any documented behavior is not guaranteed to be stable and may change at any time and without warning.

[bernhardmgruber]

TODO: these should be added somewhere:

• When to use std:: and when to use ::cuda::std (in general, for iterator traits, for stdint like int64_t or size_t)
• Explanation of directory structure (where should I create new files?)
• Organization of a single header file (license header, includes, namespace, implementation, etc.)
• Which namespaces do we use where (including internal or detail namespaces)
• What is considered "the public API" and how to communicate this?
• Where can I make changes and what is considered a breaking change?
• How to deprecate and replace a public API over time.
• Which features require new examples and how do I write them (e.g. recent CUB examples are snippets from unit test)?
• How to document which types (public facing vs. internal types)
• libcu++ headers like <cuda/foo> are not necessarily compiled by a CUDA compiler.
• each thrust benchmark should call the benchmarked algorithm once outside the benchmark loop. the execution policy caches the allocation so later invocations don't allocate. this avoids instability of the performance results.

[bernhardmgruber]

Starting with a wiki page: https://github.com/NVIDIA/cccl/wiki/Cpp-Coding-Guidelines

[fbusato]

why we don't use CCCL standard website? https://nvidia.github.io/cccl/cccl/development/index.html

[bernhardmgruber]

why we don't use CCCL standard website? https://nvidia.github.io/cccl/cccl/development/index.html

Because it's way easier to edit the Wiki than to edit the documentation. The latter has to go through git and a PR.

We can of course add the developer guidelines to the public documentation later, once we converged.