More Travis CI build fixes related to DS-2133

Travis CI continues to randomly "kill" some of our builds (ever since merging #637). However, from my tests, disabling the Mirage2 build also doesn't fully work either (see #646) -- we still get "Killed" messages at times. According to Travis CI, this is probably a Memory-related issue:
 
http://docs.travis-ci.com/user/common-build-problems/#My-build-script-is-killed-without-any-error

After some testing, I've seemingly narrowed it down to the DSpace assembly process (specifically when we build the "dspace-installer" folder itself). Sometimes Travis will perform this step fine, and other times it will return a "Killed" message. My guess is the more modules we have, the more processing/memory that assembly takes.

This PR reworks our Travis tests slightly to try and decrease the frequency of these "Killed" messages (I'm still not certain that they will disappear entirely though).

Essentially, this PR does the following:
 
1. Decreases the MAVEN_OPTS memory setting to just 1GB. It doesn't seem to really need more than that, and I don't want Java reserving too much of the total of 3GB that Travis allows us.
2. Reworks the Travis build & test into two separate steps (see https://github.com/tdonohue/DSpace/commit/217aea08c3da5b61ffeb456f1bde84591a2de9ca)
    1. First, run all Unit Tests for all source code modules (via a `mvn install`), but SKIP building the "dspace" assembly module
    2. Second, run a `mvn package` from the `[src]/dspace/` folder to actually assemble DSpace. Retry this step if it fails the first time (as this is the step that occasionally throws the "Killed" messages).
3. Adds the ability to *disable* just the assembly of the `target/dspace-installer` (by passing `-P !assembly`) should we ever need to use it. (Currently I'm NOT using it for Travis, but it may be necessary to enable if we cannot get a stable Travis build). See https://github.com/tdonohue/DSpace/commit/98acddd6c260fcdfdc51f2df29d68405d3b5251d
4. Specifically gives Unit Tests 512MB of memory by default (which seems to be more than enough). This setting is also configurable via commandline via `-Dsurefire.argLine=-Xmx512M` or similar. The maven-surefire-plugin always forks a new JVM to run Unit Tests, so it ignores MAVEN_OPTS settings (which is why this new flag is necessary). See https://github.com/tdonohue/DSpace/commit/599931f520797383d5f5f936f6a79f8cd5bb77c1

In order to achieve all this, I had to also make some minor modifications to POMs, the `assembly.xml` (mostly I tried to clean it up, and ensure it wasn't matching *too many* modules, which could cause memory issues), and the `testEnvironment.xml` (to ensure that we could SKIP building "dspace" while also running our Unit Tests).