Add new version with AppProtocol, defaulted to 0 with flow.Flow usage

[aaronfuj]

Updates the chf.CHF and flow.Flow structs to support passing in an App Protocol. An App Protocol can be used to specify the type of flow being sent (i.e. Flow, SNMP, Streaming Telemetry Interface Metrics, etc.).

This has been validated to at least avoid regression by internal services leveraging libkflow and upgrading (without changing/using AppProtocol).

By default, this will make all consumers of flow.Flow have an App Protocol of 0 instead of the previous default max uint32 value. Therefore this is not a backwards compatible change. For any users that want to retain the 'no value', they will need to manually set the App Protocol field to math.MaxUint32 or 1<<32 - 1 or decimal value 4294967295.

[cleroux]

Code seems fine. I trust your judgement on the bigger picture.

[cleroux]

This struct can be optimized to reduce memory usage by about 6% if my napkin math is correct. I only mention it because this seems like a struct we instantiate a lot. There are a couple gaps in this struct if we consider the 8-byte alignment.
I think you can add AppProtocol without increasing memory usage if you insert it immediately after TcpRetransmit uint32

Does the ordering of these fields matter to capn proto? If not we can optimize it further by grouping the bool and uint8 fields.

[aaronfuj]

I completely forgot about struct padding and packing in this way. This is indeed something that is heavily used and instantiated a lot so I think this will be pretty beneficial, but is something I'd want to do a little bit more due diligence on and have its own PR to show some before/after. For now I'll put it by the TcpRetransmit as you recommended since I agree that makes sense.

[aaronfuj]

Created #21 as the issue to track the further improvement.

[aaronfuj]

Re-verified via internal services and created #21 for the follow up improvement.