Added rich comparisons and __iter__ to _Trie

Closes issue #16.
1. I think implementing it on a lower lever worths it. Here a lot of dynamic lookups happen, lots of Python functions are called, keys are unnecessarily encoded/decoded, temporary Python objects are allocated/deallocated. A for loop which uses agent.Agent and self._trie should be much faster. Check the marisa_trie.html file generated by update-cpp.sh command, it should give some cues.

2. This implementation looks incorrect for BytesTrie and RecordTrie because it won't check the values. A lower-level implementation doesn't have this issue.

3. What about items order? I'm not sure if an order of keys depends on their insertion order or not. Check https://github.com/kmike/marisa-trie#trie-storage-options and "node order" section in http://marisa-trie.googlecode.com/svn/trunk/docs/readme.en.html. When a trie is created with LABEL_ORDER the order of keys is clear, but it is not clear for me what happens if a trie is created with WEIGHT_ORDER and all weights are the same (a default) - does the resulting order depend on an order the keys were inserted at, and if it does then is it OK to return False for trie1==trie2 when they have same items but in a different order?  

I guess it is OK to return False if one trie is created with LABEL_ORDER and another is created with WEIGHT_ORDER and they return different items because of that. This gotcha is worth documenting, though.