Fix handler exclusivity.

- Remove Handler::exclusive(). Provide more specific and clear
  Handler::allow_concurrent_handlers(), allow_concurrent_threads().
- Read handlers obey Handler::exclusive() properly. Derrick Pallas
  showed that the previous code didn't: multiple HANDLERS could
  proceed in parallel, even though a read handler would block out
  concurrent threads. This behavior disagreed with the documentation.
- Use a version of Derrick's lock-upgrade code. Also introduce lock-
  downgrading for write handlers.

Signed-off-by: Eddie Kohler <ekohler@gmail.com>
Simplify and I believe correct handler locking.

- Config handlers are NOT nonexclusive! In fact they must be
  exclusive, because they modify click_router. Previously they
  weren't even protected from one another.
- In this commit click_router and click_config_generation are
  protected by the exclusive clickfs_lock mutex.
- Most file system functions keep the exclusive clickfs_lock
  during their operation, so that click_ino is protected.
  This makes the separate click_ino_lock redundant; it was
  inadequate anyway, since writing /click/config could change
  click_router at any time.
- Will this reduce scalability? Perhaps: but note that the
  clickfs_lock was ALWAYS an exclusive mutex (we faked read
  locking ourselves). I bet this will perform simiarly, with
  respect to directory operations and such.
- Support lock downgrading for non-exclusive handlers. Downgrading
  (1) "uses" the current router (so it won't be deleted by a
  concurrent /click/config write), (2) releases the clickfs_lock.
  It is not OK to access click_router, click_config_generation,
  or click_ino after downgrading the lock, so don't do that.
  Releasing a downgraded lock reduces the refcount on the relevant
  router.