Can receive empty messages + amenities

• Added Receiver::recv_batch_up_to and Receiver::try_recv_batch_up_to so that you can
  fetch "up to n" elements from the queue or wait until one arrives.
• You can now send and receive empty messages.
• Fixed typos in the documentation.

Contributors:

• @mullr

Updated dependencies

v0.6.5

Bumbed dependencies (removed unmaintained atty crate)

Update to dependencies

Minor update to dependencies. Dependencies have not been updated for a long time. Now it's the time.

Contribuitors:

• @grant0417

v0.6.2

• Created a QueueIter which allows to iterate through a queue as a list. The interface
  is completely synchronous and has less overhead than just using the Receiver, besides
  leading to clearer code.
• Documented some undocumented items.
• Upgraded dependencies and reduced the total number of them.

v0.6.1

Only small changes and bug fixes + ReceiverBuilder and queue saving strategy.

• Introduced a new invariant: all items have to be read and used by the end of every
  transaction. I could not verify if this invariant always holds. Anyway, there is an
  assertion in the code to avoid the worse. If you find such a situation, please fill an
  issue.
• Dropping the Receiver forced the state to be saved, not the initial_state (the
  state at the begining of the current transaction). Now, Drop calls Receiver::save
  so that the behavior will be always consistent.
• We have a backup strategy for saving the queue! It invlves no asyc stuff, so it will
  only be triggered at the end of a transction. The current criterion is: save at every
  250 items read or every 350ms, whichever comes first. This should dimiinish greatly
  the necessity for external control of the save mechanism.
• Created a ReceiverBuilder to allow people to costumize the way the queue is saved.
  This includes altering the above defaults or disabling queue saving altogther.

v0.6.0

Oh, this is a big one! Expect incompatibility issues with this version but, if you are using
older versions, you are encouraged to try this one. It comes with important bug fixes.

So, here is what's new, folks:

• Changed in-disk format again. This time, things are woefully incompatible. Don't use
  a <0.5.1 queue with 0.6.0. You will fail miserably. The difference that breaks
  compatibility is one extra parity bit flag in the item header. Before 0.6.0, it was
  used to ensure "legacy mode", where no parity checking took place. Now, it is a parity
  bit all on itself. This leads to much more robust error detection (up to 2bits,
  guaranteed, but you can get lucky with more!).
• Now you can control the sender more finely with SenderBuilder. This includes
  chosing a segment size that fits your needs and chosing the "maximum size" for the
  queue.
• And yes, now you can control maximum queue size so that yaque doesn't blow up your
  hard drive. This means that some major API changes took place:
  • Sender::send becomes Sender::try_send and returns a TrySendError. The same
    thing happens to Sender::send_batch.
  • A new method called Sender::send is created that works like good old
    Sender::send, except that it is async and .awaits for the queue to shrink
    below the maximum size. The same thing happens to Sender::send_batch.
• You can also just try to receive items, without the need to .await anything. For
  each fo the receiving methods recv, recv_batch and recv_until you now have the
  try versions: try_recv, try_recv_batch, try_recv_until.
• Solved a bug regarding the rollback of batch transactions when crossing over a segment.
  Older versions will do a complete mess out of this. The side effect: commit now returns
  a Result, which has to be treated.

v0.4.3

Merge pull request #6 from otaviopace/fix/dependency-compilation

deps: update simple-logger to 1.11.0