Consistent support for 32-bit/64-bit integer types

[mehalter]

In a lot of the code in Catlab we have methods that define parameters as Int rather than Integer. Int will be converted to Int32/Int64 based on whether or not it's on a 32-bit or 64-bit machine. If we change all of these to Integer then it will generalize to integers of any bit size.

Basically on a 64-bit machine if you decide to use Int32 anywhere we won't be able to use any of the Catlab internal functions because there won't be functions defined for Int32

[epatters]

I take your point, but I'll note that a proper fix involves more than just replacing Int with Integer in method signatures. Our combinatorial data structures (acsets) would need to be generalized with an extra type parameter T<:Integer specializing the integer type and this would need to be propagated through constructors, as well as supplemented with suitable default constructors.

It's certainly possible to do this. Graphs.jl does it, for example. But for me it's not so much a bug fix as a deliberate design decision whether the extra boilerplate is worth it. My guess is that nothing will happen until someone shows up with an HPC use case where it actually matters.