[lmi] Safe to assume std::uint64_t is available?

[Greg Chicares]

Vadim--Does the patch below seem good to you? (Here, apparently the
borland workaround was preferable to the code we were using for gcc.)

I hesitate only because the exact-width integer types are optional
[18.4.1]. This section of the code is for msw only; would any C++11
(or more modern) compiler targeting msw really fail to provide uint64_t?

----------8<----------
--- ./timer.hpp2016-06-05 15:52:14.593750000 +0000
+++ a00/timer.hpp2016-06-05 16:59:46.000000000 +0000
@@ -34,15 +34,8 @@
     // Compilers for this platform use various types for its high-
     // resolution timer, but they use the same platform API, so
     // it's sufficient to use the same 64-bit integer type for all.
-    //
-    // Type double can't be used, even though it be the right size:
-    // arithmetic performed on this type requires that it be integral.
-    //
-#   ifndef __BORLANDC__
-    typedef unsigned long long int elapsed_t;
-#   else // __BORLANDC__
-    typedef unsigned __int64 elapsed_t;
-#   endif // __BORLANDC__
+#   include <cstdint>
+    typedef std::uint64_t elapsed_t;
 #else // Unknown platform.
 #   include <ctime>
     typedef std::clock_t elapsed_t;

---------->8----------