
- prime_count - needs the pc(#) option as well as pc(#,#)

- Consider adding Lehmer's method for prime count.  The only use I can really
  think of would be 32-bit machines.  I worry that the overhead of GMP would
  kill us, and some method using __uint64s, or even Math::Int64 would be
  faster.

- nth_prime

- GMP SQUFOF could use a better implementation, though low priority since it
  just isn't going to be the right algorithm for numbers > 2^64.  Mainly what
  it needs is to pay attention to the rounds argument.  Perhaps race.

- Add Riemann R function

- Tune and improve SIMPQS for our uses.  Check FLINT 2.3 for improvements.

- Write our own QS.

- The statics in ecm and QS won't play well with threading.

- ECPP: Perhaps more HCPs/WCPs could be loaded if needed?

- ECPP: Another idea is related to Atkin/Morain's EAS.  When we have a large
  number, we can process more Ds, delaying the downrun.  We then use the
  smallest q we found.  Combine with lightened stage 1 factoring as above.
  This drops our q sizes faster, at the expense of more up-front time.
  I have this running, but for small numbers it doesn't matter much, and for
  large numbers it just highlights how much nicer FAS would be.

- ECPP: with FAS, we're printing the N[i] results backwards.

- Better output for standalone ECPP.

- Convert ECPP output (prooftext or reverse NabmqP output) to Primo format.
  Looks like that isn't possible without completely changing our method of
  choosing curves and points.  Primo uses (type 3):
    A, B, T where these are usually numbers smaller than ~30
    L = (T^3 + AT + B) % N
    A = (A * L^2) mod N
    B = (B * L^3) mod N
    X = TL mod N
    Y = L^2 mod N
  Type 4 uses a single parameter J instead of A and B.  The calculations for
  curve and point selection could be modified to do this style perhaps.  It
  would definitely be a change from the Cohen or Crandall/Pomerance methods.
