Delete old ${titan.version} pom.xml property

The pom.xml property ${titan.version} has been unused for ages since
all uses of it were replaced by ${project.version}.  Having copies of
${project.version} is a DRY hazard -- better just to use
${project.version} unless there is an actual need to allow
differences, as in ${titan.compatible.versions}.  Deleted.
Delete gh-pages profile from titan-site

I used this profile to experiment with the Github maven plugin, but it
proved too destructive in testing to use in actual releases.  It
doesn't appear to offer an easy way to replace a subdirectory with a
new one a la rsync, so its tricky bordering on impractical to use it
to modify subdirectories of gh-pages's javadoc and wikidoc
directories.  All its prospective titan-site functionality has been
subsumed in the gh-pages-update.sh script anyway.
Update gh-pages index.html template
Remove symlinking from gh-pages-update

gh-pages does not support symlinks and returns 404s on them
Update outdated titan-dist/README.md
Document Titan release process RELEASING.md
Make rewrite-tag.sh more robust

This script now reads the current HEAD branch using `git symbolic-ref`
and attempts to return to that HEAD after rewriting the release tag.
Release instructions update
Update doc submodule pointer to latest wiki
Adding Metrics Ganglia and Graphite support

This commit is totally untested.  This commit also javadocs all public
methods in the MetricManager class.
Tested and tweaked Ganglia Metrics reporter

* added new Ganglia Metrics reporter configuration sanity checks
* added option to set GMetric "spoof" option
* commented body of the Graphite Metrics reporter config method until
  its implemented
* javodoc'd Ganglia configuration option constants and added their
  associated default values as constants
Cleanup imports in MetricManager and GraphDBConfig
Rename metrics.ganglia.host to .hostname

Matches storage.hostname.  There's no technical reason they have to
match, I'm just trying to stick to precedent.
Added Metrics Graphite reporter support

I just tested this against a local Graphite instance and successfully
ingested data and exercised the Graphite "prefix" config option, but I
didn't scrutinize the results beyond that.  This Graphite reporter
support should be considered lightly tested.
Major untested Metrics refactoring

Made Metrics configuration transaction-centric.  Each graph
transaction can be configured to disable metrics, enable metrics, or
enable metrics with a custom metric name prefix.  The last option is
intended to let users segregate Metrics measurements generated by
Titan in whatever way they like -- for instance, by setting the
metrics prefix to the name of an application or the name of an account
originating the tx.  User provided metric prefix strings override the
Titan default and will appear in whatever Metrics reporter targets the
user configures, such as Ganglia or Graphite.

This commit is a probably-buggy refactoring baseline.  It reflects the
broad strokes structural changes that I wanted to do in Metrics
configuration, but I've probably messed up the details somewhere.
Additional bugfix commits likely to follow...
Fix Configuration loading exception

Replace Configuration#getLong(String) call with call to
Configuration#getLong(String, null) to avoid exception when the key is
unbound
Fix getSlice Metric name mangling
Fix broken getSlice.iterator Metric names
Make StandardTitanTx increment tx counters

Before this commit, StandardTitanTx created and configured its
counters properly, but never actually incremented them.  Added three
counter.inc() calls, one for begins, another for commits, another for
rollbacks.
Fix metrics.prefix config parsing

The logic attempting to read to read the metrics.prefix key was used
the wrong config subset; moved to
GraphDatabaseConfiguration#configureMetrics()