as discussed, reverted the adition of zlist_curr
Merge remote-tracking branch 'upstream/master'

Conflicts:
	include/zlist.h
	src/zlist.c
Merge remote-tracking branch 'upstream/master'

Conflicts:
	include/zlist.h
	src/zlist.c
Merge pull request #641 from jossgray/master

Fix some build issues with msvc
merge, conflito resolvido
add zhash support o zsock picture
zlist_item was defined 2 times
fixed segfault
Merge pull request #642 from mosconi/master

add zhash support to zsock picture
Updated README
Problem: zlist got out of control

This was always meant to be a *simple* list container, otherwise
why would we go to all the pain of using a singly-linked list
rather than the obviously easier double-linked list... yet after
two days of refining the API while keeping the old API intact,
this thing isn't finished.

To make this worse, zlist is copying a lot from zring, except it
can't do it properly, lacking the backwards links.

Solution: simple is less, not more.

1. revert all changes to zlist and keep it as it was a week ago.

2. zring is a better place to (carefully) add new semantics.
Ziflist uses zring now
Problem: style was wrong in some places

- tabs in zsock (we really need to run a checker in Travis CI)

- zconfig_save_chunk was fugly and copied a lot of code from zconfig_save,
  so I refactored this code to make it simpler.

- also removed 1024 character limit on lines in saved config file.
Merge pull request #643 from hintjens/master

Reverting zlist changes, other cleanups
Added zring_sort method

Fixed czmq_comparator to return int, not bool
Problem: zring_delete is inconsisent with zlist and zhash

- zring_delete -> zring_remove
- also, zring_detach should use zring_find
Problem: need safe access to last inserted item key

Solution: set hash cursor on insert and update, so that zhash_cursor
returns this. The key is copied in the hash item, so safe to refer to
until the item is deleted.
Problem: need keyed access to zring items

We often use a list/hash combination. This is delicate for several
reasons, mainly it's unclear which container owns the item, and it
unclear when to properly duplicate and destroy items.

Solution: add a keyed access API into zring, and make zring an
authoratative container for such use cases.

  - zring_insert -> insert item by key
  - zring_lookup -> lookup item by key
  - zring_delete -> delete item by key

The keyed access cooperates with the zring list access, so that if you
remove items from the list, they're also removed from the hash. In the
same way, if you do zring_lookup, this leaves the ring cursor at the
proper place.
Merge pull request #644 from hintjens/master

Adding keyed access to zring API
Problem: zcertstore uses clumsy mix of hash + list

Solution: move to nice elegant zring hybrid.

This also exposed a proto-bug in zcertstore which would load
certificates from disk without filtering out _secret files. So
depending on the order of filenames after sorting, the secret
certificate would override the normal one, or not. It worked
by accident because _secret came after the normal filename.