feat: generic datatype for node ID

[vidarandrebo]

The node id is now a unint32, but this does not always match up with the applications utilizing gorums. If an application does not use a uint32, it would either have to resolve a node from the config using ip address, or store and exchange gorums ids at the application level.

[meling]

I think it makes sense to implement a generic node ID or a mapping from IP to a generic node ID, to avoid having separate Gorums IDs and application-level IDs. However, it would be nice to do a deeper analysis of Gorums' codebase to examine if this could cause problems in some way. @hanish520 @johningve @leandernikolaus Do you foresee any issues with this? (I haven't had time to dig into it myself yet.)

[meling]

This was attempted in #248. A slightly simplified variant was attempted in #249, but it was closed because it offered too little gain over the original version.

It is still not clear whether we want to pursue this, but we could try to clean up #248 (or start again from scratch) since a lot has changed since this first attempt. Here are some follow-up items that still look actionable:

• Reducing verbosity around NodeResponse[...] in tests and generated code.
• Adding coverage that exercises a NodeID type other than uint32. It should also add new tests that use a non-uint32 NodeID type, because the existing generic test helpers are still biased toward uint32. Those tests should live in dedicated files rather than trying to force the current helpers into a shape they do not support well.
• Introduce small aliases where they clearly improve readability without obscuring types.