Protection is eliminated.

The idea behind the protection system was that items that were sitting
in the client, but protected, would never have requests for information
fail. A noble goal. However, I've decided that it's just not worth the
effort. Here's why:

- 99.99% of the time items are protected without need. Items are already
  kept for 24 hours *after* they disappear from the source feed. So,
assuming that a client gets the item immediately before it disappears,
it still has to sit there for a full day before protection makes one bit
of difference.

- Keeping in mind that's it's extremely rare that protection would
  matter, I can't justify all of this:

    - Having logic to keep dead feeds around when they have protected
      items

    - Having to hold a lock in feed.index to check protections

    - Having to automatically protect every item sent to a client to
      keep the whole thing from being racy.

    - Forcing the sync plugin to try and reconcile protected old items
      that no longer exist in new content.

- In addition, protection doesn't mean that attribute requests will
  never fail because attribute requests can always fail. Items might not
even have a "title" entry for Chrissakes, so it's not really saving any
complexity on the client side

- Most importantly for this argument, if you really want to make sure
  you never lose an item there's keep_unread which will keep every
single item that you haven't explicitly marked read (and works naturally
without any of the bullshit from point 2).

Filter-immune protection was eliminated as well, which caused an API
change to transforms. This system was inherently racy with
multi-threading anyway (i.e. items received before filter-immunity set)

I came up with a few solutions that kept this system alive, like keeping
protected items in memory instead of on disk (which would avoid the
technical shortcomings) but when every item in a client has to be
protected by default to keep the system from being racy the memory cost
was too great just for the 00.01% case.
Add first connect and last connect hooks

"server_first_connection" is called with no arguments when a connection
is made and there were no previously active connections. So to be clear
"first_connection" can be called multiple times as long as at some time
in between calls there were no connections.

"server_no_connections" is the inverse. It's called with no arguments
when a disconnect occurs and there are no more connections.
Fixed plugin control arg parsing

This is what I get for waffling between two terms.
Implement caching options

So, it's come to my attention that not everyone runs the daemon on a
quick disk, and some people don't care enough about 100M of RAM to put
up with items taking seconds longer to load.

I also would like more information about memory costs of various
strategies.

To accomodate, I've added a -c/--cache option that will take an
argument:

    - 'on' turns the cache on all the time (similar to before the
      minimization patches). Obviously this is the fastest, most memory
      intensive.

    - 'conn' heats up the cache while connections are live

    - 'off' relies on the disk for almost everything.

Off is still the default, but I'll run some fresh metrics on memory
usage over time now that the usage pattern has changed a bit.
Remove h and help options from common args