Check for locale support in CMake

[Gachapen]

This should improve #527 by checking for locale support at configure time.

Example output from our Android build with this change:

-- Looking for C++ include clocale
-- Looking for C++ include clocale - found
-- Check size of lconv
-- Check size of lconv - done
-- Performing Test HAVE_DECIMAL_POINT
-- Performing Test HAVE_DECIMAL_POINT - Failed
-- Looking for localeconv
-- Looking for localeconv - not found
CMake Warning at third_party/jsoncpp/src/lib_json/CMakeLists.txt:25 (message):
  Locale functionality is not supported

I would also like to suggest changing NO_LOCALE_SUPPORT to JSONCPP_NO_LOCALE_SUPPORT as to not clutter the global namespace. But this would break builds relying on NO_LOCALE_SUPPORT, so I didn't implement it.

[Gachapen]

Frustrating how inconsistent the CMake API is with regards to setting language and adding headers.

[Gachapen]

I see both gcc and clang in travis fail HAVE_DECIMAL_POINT, I should look into this. It did not fail for me with clang 3.9. Travis is using clang 3.4.

[Gachapen]

I nailed it down to a change in CMake 3.0 where they added the LANGUAGE option to check_struct_has_member. Before this change, it always compiled with the C compiler, not C++.

I see some options, but not sure which is best:

• Upgrade the Travis CMake to >=3.0 and drop support for older versions.
• Change the check to use the locale.h header instead of clocale so that it can compile it with the C compiler. (lconv in the C header and C++ header might not be the same)
• Add the updated check_struct_has_member module to the jsoncpp project to fix the check. (updates to the system cmake won't affect the check_struct_has_member anymore)

[Gachapen]

I implemented the second option as it seems to be the least problematic. Now, I misread the build log. It wasn't only HAVE_DECIMAL_POINT that failed, but also the lconv size check. Possibly because of the same reason. I'll investigate more....

[Gachapen]

I amended my previous commit with a proper fix for the problem. It's not pretty, but it's the best I could do if we want to support older CMake versions.

[cdunn2001]

I would also like to suggest changing NO_LOCALE_SUPPORT to JSONCPP_NO_LOCALE_SUPPORT as to not clutter the global namespace. But this would break builds relying on NO_LOCALE_SUPPORT, so I didn't implement it.

Could you include that amendment in this PR? Don't worry too much about build-breakage. But if you fallback to NO_LOCALE_SUPPORT when JSONCPP_NO_LOCALE_SUPPORT is undefined, that might be good for now.

[Gachapen]

I squashed my two first commits, and added a commit for JSONCPP_NO_LOCALE_SUPPORT. I think it makes more sense to separate them.