Test passing state and trigger as generic types

[qmuntal]

This PR is just to view which are the changes required to adopt Go 1.18 type parameters. I'm still not sure if it is worth making State and Trigger generic compared to the overhead of having type parameters polluting almost all internal functions.

[suhlig]

I made a new attempt to make State and Trigger generic based on the latest master branch (see master...suhlig:qmuntal-stateless:generic). Tests are passing, so I believe it is ready to be merged.

While I agree that the benefit is not huge, generic type parameters improve one important thing: As I am hiding the state machine behind my project's API, generic type parameters allow me to have State and Trigger be a type of my domain, so that my API does not leak stateful.State to its users.

I was also briefly thinking about the parameters to triggers and guard functions. I believe generics would be much more helpful to define the type and arity of parameters, but I wouldn't know how to achieve that without an explosion of type parameters (basically one for each distinct trigger + guard parameter).

Overall, stateless as been a pleasure to work with. Keep up the good work!

[jwriteclub]

I also have been thinking about this and starting with @suhlig work, I considered adding an Argument generic type as well.

#88

As I mentioned in that pull request, it does add some verbosity to the core stateless code, but at least for my typical use cases, I usually don't have dynamic typing for my arguments, so it would be more convenient when writing software which uses the library. Anyway, it's provided mostly as taking a crack at it to see what it would look like.