Release HOWTO and supporting Makefile tasks.

[mookerji]

1. Updates Makefile to handle some RELEASE boilerplate.
2. HOWTO: Document some relevant procedures around releasing libraries
   and adding messages.

Closes #78.

/cc @mfine @fnoble @denniszollo @henryhallam

[swiftnav-jenkins]

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/libsbp_Pull_Requests/7/
Test PASSed.

[fnoble]

I think this should reference a section "Message Guidelines". I have a few more things that would go under guidelines, I'll follow up in another comment.

[fnoble]

I think there should be a section for "Message Guidelines". I'd suggest the following:

• Messages should be as simple as possible but no simpler.
• Build for the future - once a message is promoted to "stable" its general structure must never change. You should think very hard about what kinds of fields you may wish you had included in the future. Consider adding some extra reserved bits for future expansion (within reason).
• Size matters - this is designed to be a light-weight protocol used by small embedded devices, consider using fixed point representations where possible, don't specify excessive precision or range. Avoid non-byte aligned types though, they are a pain to decode.
• Generalize - SBP is a protocol that exists separately from any specific device that uses SBP (e.g. Piksi). It should be with a very heavy heart you include anything device specific in the protocol, and even then it should only be added to a device specific package.

[fnoble]

Also we need to have a policy around ID assignment, but its more work. Its not just arbitrary because you have to consider the implicit groupings created when using a message mask.

[henryhallam]

The message mask system is cute, but I wonder how scaleable it really is, and how much overhead it would be to support arbitrary lists of desired messages - my guess is, that wouldn't be significant hit to performance or resource usage.

[fnoble]

Agree, I would be happy to move to some kind of more granular system. The thing I have been wondering about with a whitelist type system is if you want to specify that you want e.g. all messages or all of a certain kind of message. You could put a long list in the settings but it would always need to be updated. Seems like there is a lot of potential for people to get tripped up.

[cbeighley]

I think a whitelist would be pretty intuitive - if you want a particular message, you have to add it to the list. Other way would be groups of messages but you could probably implement that on top of a whitelist.

[swiftnav-jenkins]

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/libsbp_Pull_Requests/93/
Test PASSed.

[swiftnav-jenkins]

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/libsbp_Pull_Requests/94/
Test PASSed.