Fix static_dynamic for intel compiler

It turns out that -Bstatic fails to find a static library in one case and
causes compilation to fail.  The correct combination to ensure complete and
static compilation is -static-intel -static-libgcc -static.  These tests should
now pass (phew!).
Have serial tasks directly execute the function for qthreads

Previously, serial task creation spawned a new task, and the original task
would wait for that task to complete. We believe the original motivation for
this is from the days when qthreads had a lower stack size. If you have
recursive serial tasks being created you're going to run out of stack pretty
quickly.

This was changed with the qthreads commit 82a0224513ec

With our current default stack size of 8MB you end up wasting a lot of memory
because you're creating a task for each serialized task. For schedulers that
have more than one worker per shepeherd you can also schedule the serial task
on a different core, which can cause you to lose some cache and can result in
slowdown because many qthreads are constantly yielding waiting for one to
finish.
Merge pull request #734 from lydia-duncan/fixStaticDynamicTest

Fix static_dynamic for intel compiler

It turns out that -Bstatic fails to find a static library in one case and
causes compilation to fail. The correct combination to ensure complete and
static compilation is -static-intel -static-libgcc -static. These tests should
now pass (phew!).
Move the failure mode of externFloat4calls.someFields.chpl to a future and
disable the mode it fails here.

I copied this test to a separate file so that it could be futurized without
losing the accurate results produced under other circumstances.

Throwing --no-remove-copy-calls causes this test to lose information for extern
record fields not named within Chapel, as an autoCopy does not know to copy that
information over.  The new future always throws this flag, to ensure the failure
mode is visible.
Merge pull request #733 from ronawho/qthreads-serialized-task-creation

Have serial tasks directly execute the function for qthreads

[reviewed by @gbtitus]

Previously, serial task creation spawned a new task, and the original task
would wait for that task to complete. We believe the original motivation for
this is from the days when qthreads had a lower stack size. If you have
recursive serial tasks being created you're going to run out of stack pretty
quickly.

This was changed with the qthreads commit 82a0224513ec

With our current default stack size of 8MB you end up wasting a lot of memory
because you're creating a task for each serialized task. For schedulers that
have more than one worker per shepeherd you can also schedule the serial task
on a different core, which can cause you to lose some cache and can result in
slowdown because many qthreads are constantly yielding waiting for one to
finish.
Merge pull request #735 from lydia-duncan/silenceBaselineFailure

Move the failure mode of externFloat4calls.someFields.chpl to a future
and disable the mode under which it fails here.

I copied this test to a separate file so that it could be futurized without
losing the accurate results produced under other circumstances.

Throwing --no-remove-copy-calls causes this test to lose information for extern
record fields not named within Chapel, as an autoCopy does not know to copy that
information over. The new future always throws this flag, to ensure the failure
mode is visible.