Remove joint consensus (ProposedMembers) support.

This was present in the original raft paper but was removed from the final
thesis because simpler protections suffice as long as only one node is added
or removed at a time.

Use the term "observer" consistently for non-voting members.

@spencerkimball 
The tricky part is that this means the result of a changeGroupMembership would be dependent on whether the node perceives the previous membership change as being committed, and this raises questions around idempotence (immediately after an election the new leader may not know the current commit position, although we are planning to wait for things to catch up in most cases for other reasons).

This may be moot - I think if we only look ahead one log entry at a time (instead of the entire uncommitted tail), we'll be fine even if there are multiple pending membership changes at a time.  This also alleviates some of the problems with rollbacks that I had raised on the mailing list earlier.  I'm going to explore this refactoring in my next change. It'll be theoretically less efficient (currently it's cheap for a large chunk of the log to become committed at once), but there really shouldn't be more than a few uncommitted entries outstanding at a time.