Miscellaneous spec updates from review (mostly ICS 20)

[cwgoes]

• Standardise version string (closes Standardise version string in ICS 20  #381)
• Fix initialisation logic (closes Fix the initialisation logic for consistency #378)
• Correctly handle acknowledgements of success & failure (closes Update ICS 20 spec to handle acknowledgements & failures #373)
• Alter interface to more closely mirror implementation (or vice versa)
• Clarify abort / failure distinction
• Discuss multi-hop case (closes ICS 20 should provide normative guidance on sending prefix information onwards in subsequent transfers #232)

[cwgoes]

Refactoring ICS 20 (spec & impl) to correctly handle acknowledgements, my current thought is that application-level specs should always use acknowledgement data to indicate failure instead of aborting the transaction (which is also possible). The reason I think this is preferable is that the acknowledgement data can contain detailed information about the failure, so that the original sender of the packet can handle it appropriately (this may mean different things based on the kind of packet & kind of failure - e.g. if the destination address was invalid, refund the tokens, but if the denomination was invalid, something went wrong with the version negotiation process, if there aren't enough tokens, there has been some sort of Byzantine behaviour somewhere in the system that needs to be handled, etc.)

Just aborting the transaction can't provide this because it's only 1 bit of data (success/failure) and can't communicate the difference between different kinds of failures which might need to be handled differently. Writing acknowledgements will require a little bit more state usage, but not much, and it seems worthwhile. Relayers can still elect not to relay acknowledgements of success (which are no-ops on the sending chain) in the optimistic all-ok path.

Does this make sense as a design pattern? Anything I missed?

[cwgoes]

• Also deal with source/dest channel/port arguments required in createOutgoingPacket here

[cwgoes]

Per discussion with @fedekunze:

• Alter spec so that whether or not we are the source chain is deduced from the denom
• Note a bit about future registries of "root chain" for each denom & supply accounting