@fershad / @mrchrisadams i think this is ready for a first look from you. i tried to hit the right balance between getting some maintainable types without adding too much complex typescript logic that might be a barrier to entry for contributors. but of course i'll defer to you on what that balance should be, so let me know if i should lean more toward the "fancy" typescript features or go in the other direction and make everything more explicit.

specifically the "fancy" stuff i'm referring to is in the utility types at the bottom of types.js, which i think are helpful in encapsulating some repeated patterns i found in mapping between different values, but their inner workings are probably not very approachable to a typescript beginner.

in terms of leaning toward more complex typescript logic, what i had in mind was for methods like perByte and perVisit where the return type can be different depending on the arguments to the method or to the class constructor. in theory i think we could encode that into the type system itself, which would be nice for consumers of the library since they would be able to statically infer the return type in their own code, but would involve some relatively complex typescript logic.