Guarantee FIFO ordering if timestamps are identical.

[jcheng5]

On virtualbox (where system timer seems to have less resolution, perhaps?) we
were seeing native later calls being executed in a different order than they
were scheduled, due to the timestamps being identical and the Callback class
not knowing how to break ties. Now we're keeping count with an integer.

Testing notes

You can run this code in R to check whether the bug exists. I highly recommend restarting the R session after running the test, especially if you intend to run it again, or else you may encounter false positives.

  Rcpp::sourceCpp(code = '
    #include <Rcpp.h>
    #include <later_api.h>
    
    void* max_seen = 0;
    
    void callback(void* data) {
      if (data < max_seen) {
        Rf_error("Bad ordering detected");
      }
      max_seen = data;
    }
    
    // [[Rcpp::depends(later)]]
    // [[Rcpp::export]]
    void checkLaterOrdering() {
      max_seen = 0;
      for (size_t i = 0; i < 10000; i++) {
        later::later(callback, (void*)i, 0);
      }
    }
    ')
  checkLaterOrdering(); while (!later::loop_empty()) later::run_now() 

You can also load a Shiny app via Shiny Server (OS or Pro), and use gdb -p 'pgrep R' (those single-quotes are intended to be backticks) to attach to the R process. Then hit Refresh repeatedly and quickly in the browser, this should cause a segfault. (On stock SSP setups you'll eventually hit a "Too many concurrent connections", this is an intended feature of SSP and not indicative of a bug.)

[jcheng5]

Fixes rstudio/httpuv#171

[alandipert]

long long