clarify use of flags

the flags byte of the packet header may contain user data in the low 4 bits.
receive() does not save the flags in self.flags so they cannot be read easily.
They can be extracted from the header, but only if the header is saved, which is not the default.
receive could save the 4th but of the packet heard in self.flags.
This may cause problems tough because self.flags is also used by send()
If receive() updates self.flags then the next send will use the same self.flags settings -- this is not what is wanted.

Perhaps this is not really a bug, but just needs to be clarified in the documentation.

If a user wants to set the flags byte of the header, then the receiver must save and pars the header to find the flags.
The sender can use rfm69.flags to set the flags, but the receiver cannot read the flags via rfm69.flags. They can only be read via the header.

Read the documentation and implementation around receive(), send(), self.flags, and packet-header parsing. Confirm how sender flags differ from received header flags and document the supported way to read and set them. Done means the behavior and required header-saving step are stated clearly without changing the API.

Written by the indexing model from the issue text.