Drake: Allow `size_t` and `ptrdiff_t` to be used without explicit `std::` namespace

[sherm1]

size_t and ptrdiff_t are related standard types defined in C and C++ and are very useful. In Drake we frequently use size_t without the std:: qualifier (which I think is a good idea). ptrdiff_t is used less often but should be written the same way as size_t. (That is, we are writing them as though they were in the global namespace.)

For a long discussion, see stackoverflow. Bottom line is that the C++ standard says <cstddef> _must_ define std::size_t, std::ptrdiff_t and certain other types, and _may_ define ::size_t, ::ptrdiff_t etc. and if so those _must_ be identical to the std:: definitions. Apparently all compilers actually do that, because they implement <cstddef> by including <stddef.h>, which is obligated to define ::size_t and so on. (That's why Drake works now.) So, like #pragma once there are hypothetical problems, but this will work in practice and would save us a lot of ugly std:: pollution. And ... if it ever failed we could just add using size_t = std::size_t; to a common header.

I propose that we expressly allow unqualified size_t and ptrdiff_t. Thoughts?

(Discussion moved from PR #2370)

[liangfok]

+1 for using size_t and ptrdiff_t under one condition: we add a rule to the style guide disallowing std::size_t and std::ptrdiff_t. I always think it's best to be consistent. In this case, being concise _and_ consistent is a bonus.

[david-german-tri]

Fine with me.

[jwnimmer-tri]

Even better than a hard and fast rule in code_style_guide.rst, I'd like to have cpplint enforce it. (Style rules without tool enforcement are error-prone, and waste our brain power.) It should be relatively trivial to add, and I'll volunteer do to it if we agree on this rule.

[david-german-tri]

That sounds great, but it also sounds like you're volunteering to fork cpplint?

[jwnimmer-tri]

Yes (sorta). I've already said that we should have it as a superbuild external, not a platform library. I hope / believe I will be able to integrate new out-of-source rules into it relatively easily, and manage the vendoring in a way that is easy for us to track upstream.

[sherm1]

+1 for enforcement. However, I'll add it to the style guide now in anticipation of future Jeremy magic.