o Major features and bugfixes (node selection)

    - Revise and unify the meaning of the ExitNodes, EntryNodes,
      ExcludeEntryNodes, ExcludeExitNodes, ExcludeNodes, and
      StrictNodes options.  Previously, we had been ambiguous in
      describing what counted as an "exit" node, and what operations
      exactly "StrictNodes 0" would permit.  This created confusion
      when people saw nodes built through unexpected circuits, and
      made it hard to tell real bugs from surprises.  We now stipulate
      that the intended behavior is:

	. "Exit", in the context of ExitNodes and ExcludeExitNodes,
	   means a node that delivers user traffic outside the Tor
	   network.
	. "Entry", in the context of EntryNodes and ExcludeEntryNodes,
	  means a node used as the first hop of a multihop circuit:
	  it doesn't include direct connections to directory servers.
	. "ExcludeNodes" applies to all nodes.
	. "StrictNodes" changes the behavior of ExcludeNodes only.
	  When StrictNodes is set, Tor should avoid all nodes listed
	  in ExcludeNodes, even when it will make user requests
	  fail.  When StrictNodes is *not* set, then Tor should
	  follow ExcludeNodes whenever it can, except when it must
	  use an excluded node to perform self-tests, connect to a
	  hidden service, provide a hidden service, fulfill a .exit
	  request, upload directory information, or fetch directory
	  information.

      Collectively, the changes to implement the behavior are a fix for
      bug 1090.

    - ExcludeNodes now takes precedence over EntryNodes and ExitNodes:
      if a node is listed in both, it's treated as excluded.

    - ExcludeNodes now applies to directory nodes: as a preference if
      StrictNodes is 0, or an absolute requirement if StrictNodes is 1.
      (Don't exclude all the directory authorities and set StrictNodes
      to 1 unless you really want your Tor to break.)

    - ExcludeNodes and ExcludeExitNodes now override exit enclaving.

    - ExcludeExitNodes now overrides .exit requests.

    - We don't use bridges from ExcludeNodes.

    - When StrictNodes is 1:
       . We now apply ExcludeNodes to hidden service introduction points
         and to rendezvous points selected by hidden service users.
         This can make your hidden service less reliable: use it with
         caution!
       . If we have used ExcludeNodes on ourself, do not try self-tests.
       . If we have excluded all the directory authorities, we will
         not even try to upload our descriptor if we're a server.
       . Do not honor .exit requests to an excluded node.

    - Remove a misfeature that caused us to ignore the Fast/Stable flags
      if ExitNodes was set.  Bugfix on 0.2.2.7-alpha.

    - When the set of permitted nodes changes, we now remove any
      mappings introduced via TrackExitHosts to now-excluded nodes.
      Bugfix on 0.1.0.1-rc.

    - We never cannibalize a circuit that had excluded nodes on it,
      even if StrictNodes is 0.  Bugfix on 0.1.0.1-rc.

    - Improve log messages related to excluded nodes.

    - Revert a change where we would be laxer about attaching streams to
      circuits than when building the circuits.  This was meant to
      prevent a set of bugs where streams were never attachable, but our
      improved code here should make this unnecessary.  Bugfix on
      0.2.2.7-alpha.