Refactor gsh

The gsh.sh script was created in 2008 and has been mostly unchanged since then. There are some odd programming constructs in the script, which makes it hard to follow what will be executed under various conditions.

1) A running part of the script is built around using gsh.sh using the argument "-initEnv" as a bash script sourced under the current shell, to set up environment variables instead of running gsh. But the code paths that would use this initEnv mode are all unreachable:

  - $0 is never blank in bash
  - when running as `source gsh.sh`, $0 is "bash", not "gsh.sh". Note that `source gsh.sh` is the usage output in GrouperShell, and the error message when passing incorrect parameters, so they are both misleading
  - when running as `source gsh.sh -initEnv` there is an error message "Cannot run gsh.sh -initEnv. Instead use: source gsh.sh, or . gsh.sh". See point above. Note that this exits the script, and as this is sourced under the current shell, it will likely disconnect the user
  - when running as `gsh.sh`, $0 is "./gsh.sh", not "gsh.sh", so it doesn't match any code path

The whole initEnv code section there, besides being moot, also has many strange coding idioms-, e.g. `if [ "$arg1" = "initenv" ]; then arg1=-initEnv` (i.e., if x==1 then x=1 ) (nm noticed different capitalization)

As part of the initEnv syntax, the script always checks the value of $2 (regardless of whether $1 is =initEnv), and if there is a grouper.hibernate.properties file there, it sets GROUPER_CONF to it. In the rare change someone passed an unrelated argument that happened to have the properties file in it, resetting GROUPER_CONF would be an unintended side effect

2) When GROUPER_HOME is not set before running, the script never takes advantage of knowing the full path of the executing gsh.sh. Instead it makes calculations based on the current directory. This means that calling gsh.sh from another directory by its full path (or by adding the bin path to PATH) is often not useful, unless GROUPER_HOME is already set

3) The script will prefer JAVA_HOME/bin/java over just `java`, even if the java executable is on the path. It should just trust that the user has set up the Java environment correctly, and can find the java executable. It can use JAVA_HOME, but just as a fallback rather than an override

4) Not a major problem in Unix, but certain variables are not quoted, causing errors if a path has a space; e.g., the java executable

5) GRP-1803: gsh script incorrectly assumes GROUPER_CP=${GROUPER_HOME}/conf instead of using ${GROUPER_CONF} for initialization of GROUPER_CP

6) Would be helpful to have an option to convert the Unix-style colons in the classpath to Windows-style semicolons. This would help when running under Cygwin with the Windows version of Java.