Testmode bug fix

Fixes https://trello.com/c/EgW3usAa/191-bug-testmode-doi-generation

Testmode DOIs don't need to be that complicated: according to http://ezid.cdlib.org/demo/simple, 10.5072/FK2. will suffice for making a demo DOI.
> How would it be problematic while testing?

DOIs need to be unique, even the test mode ones.

In production mode, we have a dedicated prefix __10.5061__ and our own convention for custom suffixes (__dryad.XXXXX__). We own that prefix -- nobody else can use it, so the guarantee of global uniqueness depends only on our suffixes. [DOIIdentifierProvider](https://github.com/datadryad/dryad-repo/blob/3e3036e6e45d442566f150ec933270211e922fb9/dspace/modules/api/src/main/java/org/dspace/identifier/DOIIdentifierProvider.java#L512) guarantees unique DOIs locally before registering with EZID.

In test mode, the __doi:10.5072/FK2__ prefix you're proposing for all test DOIs is not dryad-specific. Other EZID users also use it ([google search](https://www.google.com/#q=doi:10.5072/fk2)). So the prefix is not unique, and there's no convention in the test mode suffix (not even __dryad.__) to avoid collisions -- so we'll generate DOIs like __doi:10.5072/FK2.abc12__, and assume they're globally unique because they're unique within Dryad. These could easily collide with other EZID-generated DOIs. Registering or updating the DOI record would fail in one case and succeed in another, seemingly randomly.

I say it would be problematic while testing for two reasons:

1. We'd get unexpected, non-intuitive errors when the system mints a DOIs that is already registered.
2. Testing and production would have different rules - we assume we cannot get duplicates in production, but would introduce a case in testing that could get duplicates.

Of course another EZID user *could* register a DOI with "dryad" in it, but I don't think that's likely. And while the test DOIs are deleted after 2 weeks, I just think it's a bad idea to introduce more chances for weird behavior.

The [EZID site to create demo/test identifier](http://ezid.cdlib.org/demo/advanced), has some notes on this too - they show that a generated DOI will have the prefix __doi:10.5072/FK2__ and they recommend you don't enter a suffix - because they'll generate one that's guaranteed to be unique.

> Custom remainders (suffixes) should be unique and opaque. By opaque, it is meant that the alphanumeric string has no meaning. EZID strongly discourages placing brand strings in the remainder because successor organizations do not often honor previous brand and name assignments.