When OPTIMIZE!=1, use the -hdevelop feature on CCE.

From the CCE team:

If you compile with -hdevelop at our default optimization level (i.e. no
other command line options), then the compiler attempts the usual -O2
optimizations but throttles back some things that are known to increase
compile time.  For example, we may run certain optimization passes once
instead of multiple times, we may take a fixed-point optimization and have
it loop once instead of two or three times, we may adjust thresholds of
heuristics, etc.  These changes are targeted at reducing compile time
without affecting optimization quality in the majority of cases.  The
-hdevelop option has a completely different philosophy than -O1 or -O0,
which do not run certain optimizations at all and are not specifically
intended to reduce compile time, although they may as side effect.

Basically -hdevelop is to be used in situations where you're compiling
frequently (i.e. developing), you want to reduce compile time, and either:

(A) Using -O0 or -O1 happens to increase compile time, which actually can
happen in some scenarios, since the compiler doesn't remove as much dead
code and spends a bunch of time analyzing and generating useless code.

-or-

(B) Using -O0 or -O1 caused your runtime performance to reduce
significantly.  Presumably even if you are recompiling a lot, you
still run your code occasionally to make sure that it works correctly.
If the runtime increased so dramatically with -O0 or -O1 that it
overwhelmed your compile-time savings, then -O0 or -O1 didn't speedup
your development cycle.
Add a test that noinit works with complexes

I realized that while I tested this case, I didn't commit a test for it.  Seemed
like a good thing to do.
Add a test on the use of --no-use-noinit with complexes

I also neglected to add a test for complexes here.  This is particularly
relevant, because the module definition of complexes requires noinit always be
honored, due to the implementation of type defaults in module code.  It is our
intention to alter the type default implementation, and in such a way that
noinit can be skipped in the modules when --no-use-noinit is through.  This
test ensures that complexes work before and after such a change takes place,
(it would be one of many tests that would fail if the implementation of
--no-use-noinit were broken, but its presence should indicate more quickly what
precisely has gone wrong).
Merge pull request #1034 from thomasvandoren/use-h-develop-with-cce-comp

When OPTIMIZE!=1, use the -hdevelop feature on CCE.

If this is not a --fast compilation or OPTIMIZE=1 is not set, use the cce
-hdevelop feature. It improves compiler time by throttling certain things in the
compiler that are known to add time. It is not the same as -O0. See the man
page for details.

### How much of a difference does -hdevelop make?

On a Cray system, using the quickstart configuration and
CHPL_LAUCHER=none, using `-hdevelop` is ~20% faster when
compiling `hello.chpl`. 

I did this with master and this branch to get the above results:

```bash
git checkout <branch>
source util/quickstart/setchplenv.bash
module load PrgEnv-cray
export CHPL_LAUNCHER=none
make -j
make check  # verify things work

# verify -hdevelop is present, or not
chpl --print-commands test/release/examples/hello.chpl
# -hdevelop should never be present with --fast
chpl --fast --print-commands test/release/examples/hello.chpl

# test it
for i in $(seq 1 5) ; do echo $i ; time chpl test/release/examples/hello.chpl ; done
```

With -hdevelop the real time for each of the compiles was 8.0 seconds (+/- some
hundredths). Without -hdevelop (i.e. on master) the real time for each of the compiles
was 9.8-10.3 seconds.

I did not test compile time for bigger codes or other configurations.

r: @bradcray
Merge pull request #1036 from lydia-duncan/noinitComplexTest

Noinit complex tests [not reviewed]

I realized I forgot to add a noinit and --no-use-noinit test
involving complexes. The noinit case is more a sanity
check, but the --no-use-noinit test ought to be a good
indicator of what went wrong (and when something
goes wrong) should complexes fail again. The reason
they don't fail right now is because --no-use-noinit
does not affect the use of noinit within the standard
and internal modules. The determination of the
default value for complexes relies on noinit being
applied, at the moment. We expect that to change in
the future, and this test will make sure that complexes
continue to work throughout.