ASGARD-1293: adds APP_GROUP to user data for instances
Fixed IDE warnings, added better return types, added missing GroovyDocs
Worked around grails reloading issue for certain services at development time
Slowed down ajax poller for task screen, now that some tasks will require slow remote calls across two Asgard machines
Refactored, documented, and unit tested RestClientService

Reduced repetitive code and to use objects and variables to encapsulate important values.
Removed legacy unused optional parameter swallowException.
Created unit test for ServerController.runningTaskCount
Renamed a method to be more specific, and added unit tests

Changed TaskService method getRunningInMemory to getLocalRunningInMemory. This is in preparation for creating methods like getRemoteRunningInMemory for tasks on other Asgard instances in the same cluster.
Made it possible to configure otherServers for local development of multiple Asgards, or for data center Asgard deployments that should share an in-memory task list.

Also enabled the overriding of the port choice for other servers in the same cluster, in case the port cannot be gotten from Eureka.
Added unit test for creating GroupedInstance
Added multiple ways to find a callable server name or IP for a GroupedInstance

Refactored to reduce Cyclomatic complexity in CodeNarc's eyes
Created EnvironmentService to enabling mocking of the environment for unit tests
Exposed region environment variable key for reuse.
Made it possible to list all other servers sharing a logical cluster with the current Asgard instance.

This will allow any one Asgard instance to figure out the server names of all the other Asgard instances that should be sharing visible state, such as a task list merged from all the in-memory task lists of all the Asgard instances in the cluster.

The cluster can also be determined a system property like -DotherServers=localhost:8081,localhost:8082 for testing and -DotherServers=asgard102:80 for logical clustering in a data center.
Refactored several unit tests from JUnit to Spock
Enabled parsing of a UserContext json blob by Jackson
Enabled Jackson serialization and deserialization of Region objects with backward compatibility.

Jackson will now serialize Region objects to code values like "us-east-1".

Jackson will now deserialize Region objects from either code values like "us-east-1" or enum names like "US_EAST_1". This means existing JSON blobs with Region enum names in SWF workflow execution tags can still be deserialized, and so can the preferred newer style of serialized blob that uses an AWS region code.
Omitted closure fields from toString of EntityType, for easier comparisons in unit test failures
Enabled Jackson to create a Task from a JSON blob

Omitted non-field getters from Jackson serialization on Task.
Added a unit test for round-trip serialization and deserialization of a list of Task objects.
Made JSON parsing tolerant of unknown and missing fields for Task and UserContext.
Declared a Spring-managed Jackson ObjectMapper for reuse by other beans
ASGARD-1188 - Task list and task detail should pull data from local Asgard plus all other Asgards in cluster

To make it possible to deploy a new Asgard machine without waiting for the running task count to drop to zero, Asgard's running task list and task detail screen (with Ajax updating of fields) need to pull from a combination of the local Asgard instance and all other Asgard instances in the same cluster.

For local testing, it would also be helpful to be able to specify a configured list of port numbers for the multiple Asgard instances that could be running on the local workstation.

This change is part of the solution to enable us to deploy Asgard whenever we want whether it's in use or not. If we don't do this, then instead we would need a very complicated deployment script that reimplements some of the unfortunate concepts in the old data center deployment script.

We have data center oriented deploy scripts and traffic switching functionality for safely deploying Asgard while it's still stateful, and while people are still using it, without any downtime. Because Asgard is still stateful but still needs to be available during deployment time, we need to create new functionality to create new ASGs and switch traffic intelligently in the cloud using ASGs and ELBs at the right moment (when in-memory task count reaches zero) rather than sending SSH messages to the data center Citrix load balancer to switch traffic.