Replace NDEBUG with custom flags to avoid ABI issues

[jslee02]

• Replaced NDEBUG with custom flags to avoid ABI issues for ABI of the library depends on the value of NDEBUG? #1795.
• Added DART_ prefix to avoid potential name conflict.
• Consolidated custom flags for release mode into DART_BUILD_MODE_RELEASE to simplify, based on usage.
• Included config.hpp whenever needed
• Fixed typos

Resolves #1795

---

Before creating a pull request

• Document new methods and classes
• Format new code files using ClangFormat by running make format
• Build with -DDART_TREAT_WARNINGS_AS_ERRORS=ON and resolve all the compile warnings

Before merging a pull request

• Set version target by selecting a milestone on the right side
• Summarize this change in CHANGELOG.md
• Add unit test(s) for this change
• Add Python bindings for new methods and classes

[traversaro]

Thanks! I just noticed something, that anyhow I am not sure about. If I recall correctly, Debian packaging set the CMAKE_BUILD_TYPE to None (i.e. empty string) and then it sets the release compilation flags itself, for keeping consistency across packages. Probably it could make sense to ensure that the release bits get compiled even if CMAKE_BUILD_TYPE is empty? fyi @j-rivero @azeey that I guess are interested in this.

Another use case that I am currently not interested in (as I also use Ninja in Windows) but that it could be affected (and I did not realized this while doing my original suggestion of using the config.hpp, sorry!) are Cmake multiple-config generators, such as Visual Studio, Xcode where the CMAKE_BUILD_TYPE is not used to specify the build type, as the build type is not fixed at configuration time. I guess it is ok not to support them, but probably it is better to print a clear error in CMake.

[jslee02]

Thanks for pointing these things out!

I wonder if setting it to RELEASE by default sounds like a practical fix for the Debian scenario. It would ensure we don't miss out on crucial optimization flags for release builds, and I'm leaning toward trying this approach.

Detecting these at configuration time is tricky since they're designed to let you choose the build type later. One idea could be to check the generator used during the CMake configuration phase. If we can identify multi-config generators, we might either set a default build type or warn that this setup needs a specific build type to be chosen at build time.