Fix failing tests

  * brooklyn.util.ResourceUtilsTest.testGetResourceViaClasspathWithoutPrefix() fails on windows paths when OSGi is used
  * Explicitly wait for osgi framework shutdown before deleting the cache folder so all files are unlocked
  * LocationUsageTrackingTest.testUsageIncludesStartAndStopEvents - the test excludes the start and stop ms from the range of possible values
  * Temporary file and folder creation wasn't deterministic, resulting in unexpected exceptions
  * UsageResourceTest - guarantee the 1ms delay that the test assumes at specific points (can't use dates in the future)
It is as random as *advertised*, but not as random as a caller might think it is, including me!

I suggest saying "with length 4" it is "not unlikely (15% chance)" -- rather than "highly probable" -- that you'll get duplicates in the first 2000 attempts.

Probably worth noting "with length 8 there is a 1% chance of duplicates at 2M and a 50% chance of duplicates at 16M", as we use length 8 when we really care about uniqueness.

Even that is much sooner than I expected however.  We could use length 12 (puts us in the range of 7B before a 1% chance of duplicates, by my calcs) -- though I tend to think a better option is a pluggable unique identifier source, which we've discussed and would be quite useful in any case, also allowing ID to indicate time order when that matters or origination (in a distributed context).  /cc @aledsage