Add ENABLE_PRIVATE_APIS guard for internal API

[wismill]

Follow-up of #414. See @whot comments

[whot]

I had a look at -DENABLE_PRIVATE_APIS again (which apparently I introduced) and the original reason for it was that we have the same tool but with different functionality - the installed one links against libxkbcommon but the one in the builddir statically compiles against it. So that #define doesn't actually enable any private APIs, it allows the tools to use such an API (the difference might be hair-splitting).

More importantly though: this doesn't affect libxkbcommon.so because that one uses symbol visibility anyway and we shouldn't ever leak any symbols.

So my opinion here is still that we don't really need this, the only user of those symbols is the test which also statically links libxkbcommon.

I'm not sure if saving the 500 bytes is really worth it. I know floppies are no longer produced but still ;)

[wismill]

@whot I agree the semantics may not be great. Maybe ENABLE_TEST_API is better?

I'm not sure if saving the 500 bytes is really worth it. I know floppies are no longer produced but still ;)

Sorry but I cannot resist: with this kind of reasoning we would end with fat libraries all around. Libraries that are downloaded millions (billions?) of times. I do agree in our case the gain is small, but I do not understand why so much resistance. I mean, the patch is trivial and mean no real maintenance.

[whot]

Developer mental load, primarily :) One more thing to keep track of even though it has effectively zero effect since the symbol is private anyway. Which means guessing why the ifdef is there when it has no effect, looking up the git history (if available, too many times now I find myself in code where that is not the case...), etc.