admin api to fetch orphaned keys/entries
Updated build.properties and release_notes for release 1.2.0
Fixed the re-introduction of BindExceptions upon start up of some recently added tests:

All of the following tests directly used the method ServerTestUtils.startVoldemortServer
  test/unit/voldemort/client/ClientRegistryTest.java
  test/unit/voldemort/client/AdminFetchTest.java
  test/unit/voldemort/client/EndToEndRebootstrapTest.java
  test/unit/voldemort/store/system/AsyncMetadataVersionManagerTest.java
  test/unit/voldemort/store/system/SystemStoreTest.java

This method of starting Voldemort servers is susceptible to
BindException errors. Unless something very fancy is being done, the
method ServerTestUtils.startVoldemortCluster should be used to start a
cluster within a test.

test/unit/voldemort/client/ClientRegistryTest.java extended from
TestCase. This is a "Junit3" idiom that we should not use in new
tests. The Junit4 approach to tests relies solely on annotation.
Better documented the risks of invoking ServerTestUtils.startVoldemortServer

test/common/voldemort/ServerTestUtils.java
- Renamed startVoldemortServer to startVoldemortServerInMannerThatMayResultInBindException
  (The name is intentionally long and annoying. There are some tests
  that must call this method bare, but that should be strongly
  discouraged!!!)
- Added method header that encourages BindException to be caught and masked
Addressed most review feedback on BindException fixes.

.classpath
- fixed error I introduced.

*RebalanceTest.java
- refactored to reduce cut&paste code
- added comments and one TODO about attempting a proper fix wrt BindExceptions later.

ServerTestUtils.java
- renamed method back to startVoldemortServer
- added 'throws BindException'

test/unit/voldemort/scheduled/StreamingSlopPusherTest.java
- added comment clarifying why this test is hard to harden against BindException issue