In C, when the integer part of a double exceeds the maximum int64, casting
the double to int64_t is undefined behavior.  On some platforms, the result
is 2**64-1 and on others it is -2**64.  That results in rng.geometric()
returning -2**64 when p was sufficiently small on some platforms.

The fix is to never invoke undefined behavior by ensuring we don't attempt
to cast very large double values to int64_t.

Changed alpha value error to pass a null value. This way, dirichlet function (on the generator, not mtrand) won't raise a value exception at 0. Also added test.

API: Add `rng.spawn()`, `bit_gen.spawn()`, and `bit_gen.seed_seq`

This makes the seed sequence interface more public facing by:
1. Adding `BitGenerator.seed_seq` to give clear access to `_seed_seq`
2. Add `spawn()` to both the generator and the bit generator as
   convenience methods for spawning new instances.

I somewhat remember that we always meant to consider making this
more public and adding such convenient methods, but did not do
so originally.
So, now, I do wonder whether it is time to make this fully public?

It would be nice to follow up at some point with a bit of best practices.
This also doesn't add it to the `RandomState`, although doing it via
`RandomState._bit_generator` is of course valid.
Can we define as this kind of access as stable enough that downstream
libraries could use it?  I fear that backcompat with `RandomState`
might make adopting newer things like spawning hard for libraries?

TST: Skip when numba/numpy compat issues cause SystemError

numba is a bit buggy when wrapping ufuncs, so what should be nothing
is (on non dev versions) a SystemError and not even an ImportError.

So simply catch those too, since it can be a confusing error during
dev otherwise.

Note that unfortunately, compat does expose _inspect as well,
so the import remains (just the definition place moves).