Improve metric summarization performance under heavy load

When computing summary metrics, gmetad's current behavior is for
each cluster thread to grab the summarization lock, peform all of
its summarization, and then release the lock. This can block the
global aggregation thread if a single cluster is taking a long
time to summarize its RRDs for whatever reason; this issue
manifests are dropouts in the cluster and grid summary RRDs. This
also comes up if you have a large number of large clusters which
each take a long time to summarize.

The change here is to have each cluster thread perform its
summarization into a "pending" hash table independently, and then
once the summarization is complete each thread 1) grabs the lock,
2) swaps in the finished pending hash table with the fully-
aggregated one, and then 3) releases the lock immediately.
This significantly reduces the amount of time that the
summarization lock is held by each cluster thread, and also
eliminates the possibility of a single blocked cluster thread
preventing all summary metrics from being written.
Make gzip output for TCP accept channels configurable per TCP accept channel and
not global. This is to make it more consistent with the reset of the configuration.
Also allows mix and matching TCP accept channels if a user desires. Default is disabled.
To enable set

gzip_output = yes
Need to remove gzip options from the command line
Add couple useful but commented out options to default config. Such as

buffer = for udp
override_hostname
gzip_output
Merge pull request #92 from comptonqc/patch-pending_summary

Improve metric summarization performance under heavy load
Merge pull request #103 from vvuksan/master

Move gzip output into tcp_accept_channel and better conf file documentation
first attempt at adding support for riemann
missed riemann config vars
add mutex for riemann send msg
update configure file
minor bug fixes to riemann
add grid, cluster, resource as attributes
use strtoknize()
add standard key value attributes to user-defined ones
description wont be supported
Treat mc_bytes as a gauge (part 2)
send the basic system metrics in a timely fashion

This should avoid the "negative total memory" problem people see in
their reports after restarting daemons.
Merge pull request #107 from cburroughs/neg_mem_total

send the basic system metrics in a timely fashion
Merge pull request #106 from sflow/master

Treat mc_bytes as a gauge (part 2)
send heartbeat metric