can't set LIGOTimeGPSVector.deltaT from np.int64

@karl-wette I observe the following both from latest release and today's master (c6b3ef88):

import lalpulsar
import numpy as np
time_gps_vector = lalpulsar.CreateTimestampVector(1)
time_gps_vector.deltaT = 1800
time_gps_vector.deltaT = np.int64(1800)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: in method 'LIGOTimeGPSVector_deltaT_set', argument 2 of type 'REAL8'

Same for np.int64, while np.int seems to be accepted.

(As usual, it also took me a while to parse this kind of counter-intuitive error message: when it says "argument 2 of type 'REAL8'" what it really means is "the argument should be a REAL8 but it actually is not", i.e. the exact opposite... but I think this is a basic issue from the python or SWIG side, nothing in your control.)

This minimal example is of course highly constructed, but it comes from a real use case in PyFstat where we set deltaT from the output of np.unique(Tsft_list)[0], where the Tsft_list contains regular int but the numpy output is just that problematic np.int64 type:

>>> Tsft=1800
>>> type(Tsft)
<class 'int'>
>>> Tsft = np.unique([Tsft])[0]
>>> type(Tsft)
<class 'numpy.int64'>

We can of course avoid the problem on our side with one more explicit int() cast, but it looks like some underlying SWIG issue: it can convert standard int to REAL8, but not the numpy types. Is this known and "wontfix", so that we should just do the workaround, or can you imagine a more fundamental solution?

(Fwiw, I'm aware that this structure actually want's a float and not an int, but since deltaT <-> Tsft in most CW use cases and in other places an int is specifically required, we try to force any Tsft to integer internally. But we haven't had to worry about different python/numpy integer types before, so checking in if this is generally known as an area of fragility, or can be fixed on the lalpulsar/swig side.