P2 memory use optimizations.

Related to NXCM-4391 and others.

* In case of proxy repositories, DOMs were always loaded and persisted in way, that both,
  DOM and it's serialized for (as ByteArrayOutputStream) existed in memory (heap).
* In case of group repository, all of the DOMs were created at once, to have them merged.
  That means that count(members) + 1 merged DOM existed in memory (heap) after merge, and same serialization problem stood as for proxy repositories too.

My test case was 2 proxy repositories for Eclipse Indigo, and one P2 group having them both.

For measurements and verification used Nexus 2.1-SNAPSHOT with following setup:

* two P2 proxies for Eclipse Indigo (remoteUrl: http://download.eclipse.org/releases/indigo/)
* one P2 group having both of them

All this just to handle large amounts of metadata (indigo repository is huge).

Results:

* before fix, Nexus was on "normal" heap size of 150-200MB while working, but it peaked at 850MB-900MB (and around 900MB OOMed) when merges happened at group level.
* afteer fix, "normal" heap sizes remained same, but peaks never went over 600MB, I had never OOM with "out of the box" memory sizing of Nexus pro.

Still, this is NOT the real fix, as real fix would involve more tweaking, as things are not yet ideal. DOM for group repository might still be huge (well,
same stands for proxy repositories too), so we probably need bigger change here...
Fixes for previous "mem optimization" commit:

* proper cleanup of temp files (they were left "dangling" in prev commit)
* getting rid of deprecations
* "streamlining" use of proper exceptions
NEXUS-5104: P2 repository metadata update did not honor "localOnly"

P2 repository metadata update flag did not honor the localOnly flag
of requests, hence, it was possible to trigger md update even
over the UI by just browsing the repository.

(Equivalent would be for M2 repository, to have Nexus proxy and update
if artifact/metadata is old while you are browsing the Storage Tree
over UI, which never happens. The "/content" is different, and same
stands for P2, by "browsing" over "/content" updates/fetches WILL
be triggered for P2, just as is for M2 stuff)
Fixing one failed IT: NXCM3339P2GroupMemberRetrieveErrorIT#wrongRemoteUrl

Another implementation difference between M2 and P2: when wrong remoteUrl
used for proxy repository, M2 would just bore you with 404s, while P2
(the engine) would try to "communicate" this with you using RuntimeException.

While RE was handled in some cases (P2 group), it was not handled in case of
direct proxy access, and Nexus would response with HTTP 500 Internal Error
which is untrue.

Now, a misconfigured P2 proxy (having wrong remote URL) will behave same as
as M2 proxy: just spit out 404s, while the original handling logic is still here.
Applying comments from Ben.

Removing the "put into context" part as it is confusing, and explaining
in comment what _could be done_ once we realize we have execution paths
that needs DOM multiple times...
Deprecated the newly added FileContentLocator as same class is
being added to Nexus 2.1 core too.

P2 plugin does not depends on Nexus 2.1 (so to be able to work with Nexus 2.0)
but once the plugin dependency for core changes to Nexus 2.1, this newly added
class should be removed and it's use replaced with the newly introduced core class.
Merge pull request #15 from sonatype/p2-memory-optimization

P2 memory use optimizations.