Refactor logging macros

[timmoon10]

Changes:

• Removes the logging macros from the installed headers. The installed headers are now pure C. There are now separate headers in common and each of the frameworks (I'm open to suggestion on this design).
• Reimplements the logging macros in common to use the string utility functions and to improve the error messages (see check_cublas file and line is not helpful #376).
• Follow the Google style guide for header includes in the files that I touched.

The refactored logging macros are backward compatible, but it's now easier to make descriptive error messages. For example, consider:

TransformerEngine/transformer_engine/common/transpose/transpose.cu

Line 130 in cbfb8c6

NVTE_CHECK(input.data.shape.size() == 2, "Input must have 2 dimensions.");

We can now do something like:

NVTE_CHECK(input.data.shape.size() == 2,
           "Input must have 2 dimensions, ",
           "but found ", input.data.shape.size(), ".");

Closes #376.

[timmoon10]

/te-ci

[timmoon10]

/te-ci

[ksivaman]

We would have to also change to the correct includes for the cpptests

[timmoon10]

/te-ci

[timmoon10]

/te-ci

[ksivaman]

Why not reuse logging across the FWs?

[timmoon10]

As I see it, common has three kinds of headers:

1. Public C API headers (common/include/transformer_engine/transformer_engine.h)
2. C++ headers that are shared between frameworks (common/include/transformer_engine/logging.h)
3. C++ headers for internal implementation (common/util/vectorized_pointwise.h)

Currently (1) and (2) are combined together in common/include/transformer_engine. I'd prefer to avoid the frameworks accessing (3) as much as possible (although there is leakage in PyTorch due to the attention infrastructure). It would also be better if we didn't expose (2) to external users.

This PR makes logging.h depend on common/util/string.h. I see a few solutions:

1. Move framework-common header to something like common/include/transformer_engine_utils, which is exposed to the frameworks but not installed with the C API headers.
2. Remove logging.h from the installed headers and reimplement in frameworks. This gets rid of the framework-common headers.
3. Move string.h to common/include/transformer_engine.
4. Expose implementation headers in frameworks.

I think (1) is the right answer, but it's more complicated. (2) and (3) are simple, but have some iffiness. I don't like (4).

EDIT: Looking at #393, (4) doesn't seem as bad. The CUDA utilities are sufficiently complicated to make reimplementing a bad idea. I think the main difference is how the headers are called. #include "common/util/logging.h" is clearer than #include "util/logging.h".

[timmoon10]

/te-ci

[ptrendx]

I would probably prefer changing current common directory to core or libtransformer_engine and have common directory as an actual source for common code across both core and the FW-dependent code, like the logging.

[timmoon10]

I would probably prefer changing current common directory to core or libtransformer_engine and have common directory as an actual source for common code across both core and the FW-dependent code, like the logging.

Should we handle that now or in a future PR? That would significantly increase the scope of this refactor since we would need to change the build system to build the "common" library separately from the "core" library. I think there's value in improving the logging quickly.

[timmoon10]

/te-ci

[timmoon10]

/te-ci

[ptrendx]

Please rebase to the current main.

[timmoon10]

/te-ci