Namespacing for C++

[Manishearth]

Sub-issue of #103

Steps:

• Basic C++ namespacing support Namespace types in C++ #428
• Namespace capi code (Namespace c-in-c++ #512)
• Move namespaced headers to a namespaced folder (optional)

[Manishearth]

I don't think we ever recorded the results of this discussion properly (or if we did, it's in an issue we can't find), but the consensus between @sffc , @robertbastian , and I, if I recall correctly, was:

• We no longer have #ifdef __cplusplus anywhere. People wishing to use the C headers from C++ must wrap the include in extern "C", which is standard practice. (Get rid of __cplusplus ifdefs #490)
• The cpp-c2 headers become semi-private/internal headers that cannot be used from C anymore. You can still type cast and use the C API when needed.
• cpp-c2 code is now namespaced just like the cpp code, though it lives under an additional capi namespace (e.g. icu4x::properties::foo vs icu4x::properties::capi::foo

This means that C++ clients of ICU4X get no global namespace pollution, and C clients don't have to deal with C++-specific stuff. Clients using both can use both, if they wish to share types between both it is a little bit of work but that kind of type sharing is only marginally supported anyway.

[sffc]

Some discussion:

• Does this work with the ODR?
• Would be good to inline the C decls into the C++ header files so we have just 2: .d.hpp and .hpp. It creates some implementation complications but the outcome is nicer.
• Is there something weird about how this interacts with results? It sounds like we need to refactor how we do results.

Conclusion: If possible, try to inline C decls and result types into the header files so there are no more .h files. Otherwise, follow plan to stuff .h files under capi/.

@Manishearth @robertbastian @sffc @younies

[Manishearth]

#512 finishes all the stuff I consider mandatory here.

@sffc how important is it for namespaced headers to also be organized in folders named after the namespace? The main reason to do so is to allow name conflicts, but we could also handle that some other way (allow people to override the header file name with an attribute).

It's a change we can only make pre-2.0, but the more I think about it the less necessary it seems to me. Most c++ libraries seem to organize their headers flat (mostly)

[sffc]

Hmm, flat is probably fine; fewer decisions to make.

[Manishearth]

In that case I think #512 fixes this!

[Manishearth]

There's quality of life stuff we can do from here on, like the ability to pass in a default namespace from the CLI, but that's not mandatory for stability.