Remove restrict (for the most part)

[eboasson]

A lot of "restricts" were sprinkled throughout the code, for the most part completely unnecessary because it didn't even involve performance-sensitive code. C++ does not have the "restrict" keyword, and the work-around for that was #defining it away, which breaks C++ code using "restrict" as an identifier. In short, a bit of a mess.

This removes the vast majority, including in particular all in the API and thus eliminating any need for a C++-specific workaround. The only cases that remain are in the (de)serializers because:

• they are performance-sensitive
• they read/write through "char *" pointers that are allowed to alias anything
• a cursory inspection of the output of gcc suggests it does affects the code

This PR sits on top of #2124, mainly because of laziness. The two PRs are not entirely independent (because of the serializer), but this PR can easily be changed to apply to master if this one gets the green light but the other one does not (yet?). The changes exclusive to this PR are all in a single commit, so it is pretty easy to review the restrict part without having to wade through unrelated changes.

Fixes #2140

[dpotman]

The changes look fine to me! I agree with removing most of the restricts, as in many of these code blocks it isn't relevant because there are no loops doing memory access or not used in a path where performance is critical.

Removing restrict for const parameters and only keep it for the non-const (e.g. in plist) seems to be fine, as it follows this example. But on the other hand, e.g. the memcpy functions in C do use it on both parameters, although that seems to be just for clarification and not strictly necessary.

Not completely sure about some generic ddsrt functions like ddsrt_strlcpy and ddsrt_strlcat, that pass the parameters directly into memcpy. So src and dst need to be restrict, and wouldn't it be good to show that in the declaration of these functions?

In cdrstream, what the reason for removing restrict on the write functions? Some of them use memcpy, so I'd expect the os parameter (or the buffer in os) to be restrict?

[eboasson]

I rebased the PR on current master, which needed a few touch-ups after the fixes in the wstring-support. Those are really trivial: dds_stream_reuse_string_bound and wstring_from_utf16 gained a restrict (I overlooked it before).