refactor tree iteration

[molpopgen]

This PR implements a "natural" iterator over trees:

• New type for which we impl Iterator.
• New function TreeSequence::trees returning the iterator.

[molpopgen]

To make this viable, we need to extract
the public API for a tree into a separate
struct. Then, use Deref to access it.

[molpopgen]

Due to the ownership semantics of a tree sequence on the C side, we may not be able to do this safely w/o using Rc to manage the lifetime of that C side allocation. Being able to collect into a vector of trees hides the fact that those data must have a lifetime tied to the tree sequence somehow.

[molpopgen]

Difficulties for this PR include:

• It is (or seems to be) very difficult to do this in a safe fashion.
• On the C side, the memory for a tree is re-used.
• In rusts, all Iterators implement FromIterator via a blanket implementation.
• The blanket implementation allows one to construct a vector of trees
  as a one-liner.
  All trees except the last will be invalid.
• Further, trees hold non-owning pointers to their tree sequences on the C side.
  Rust cannot be psychic here.
  So the tree sequence can be dropped and not invalidate code using a collected
  vector of trees.
  (A work around for this is API changes that error/return None if the pointer is NULL,
  but that is moot because all the tree arrays are invalid.)

The safest method is the current use of a lending iterator.
To get idiomatic iterator behavior w/o the blanket FromIterator behavior seems to mean
rebuilding a bunch of iterator traits from the ground up.
It currently seems silly to do that much work.

Ways to work around some of these difficulties:

• Change the rust API for the trees to return None if elements like the parent array, etc., are NULL.
• Likewise, have checks that the tree sequence pointer is not null for any tree functions referring
  back to the tree sequence.

All of these workarounds are too big for a single PR.