Add a future related to param functions and intents

When a function with an out intent is converted into a syntactically valid param
function, the value of the out argument that is visible after the function has
executed is changed to the default value for that type.  This seems surprising
to me: if we don't expect out, inout, and ref intents to work for param
functions, we should generate an error message, and if we do expect them to
work, this is still a bug.  This future documents that tension.
Respond to Vass's comments on the pull request.
Merge pull request #1019 from lydia-duncan/paramFnFuture

Add a future related to param functions and intents [reviewed by vass]

When a function with an out intent is converted into a syntactically valid param
function, the value of the out argument that is visible after the function has
executed is changed to the default value for that type. This seems surprising
to me: if we don't expect out, inout, and ref intents to work for param
functions, we should generate an error message, and if we do expect them to
work, this is still a bug. This future documents that tension.
Simplify third-party Makefiles.

This is a follow-up to https://github.com/chapel-lang/chapel/pull/1013,
which simplified third-party/gmp/Makefile{,.include}.  That passed
nightly testing last night, so now we're doing the other third-party
packages.

First, in Makefile.include (or for llvm, Makefile,share), change the
ordering of the make(1) variable definitions to be generally:

  base and unique build dirs
  build dirs
  install dirs
  source dirs and files, if any
  lib dirs and files, if any

Second, these lines in Makefile were superfluous:

  <pkg>_ABS_DIR = $(shell pwd)
  <pkg>_INSTALL_DIR = $(<pkg>_ABS_DIR)/$(<pkg>_INSTALL_SUBDIR)
  <pkg>_BUILD_DIR = $(<pkg>_ABS_DIR)/$(<pkg>_BUILD_SUBDIR)
  <pkg>_DIR = $(<pkg>_ABS_DIR)

Because <pkg>_ABS_DIR isn't referenced anywhere else, they're equivalent
to:

  <pkg>_DIR = $(shell pwd)
  <pkg>_INSTALL_DIR = $(<pkg>_DIR)/$(<pkg>_INSTALL_SUBDIR)
  <pkg>_BUILD_DIR = $(<pkg>_DIR)/$(<pkg>_BUILD_SUBDIR)

But these latter two definitions of <pkg>_{INSTALL,BUILD}_DIR are
identical to the ones in Makefile.include, which is included here by
virtue of ../../make/Makefile.base being included at the top. So they
can go. And the first definition here is effectively the same as this
one that is already in Makefile.include:

  <pkg>_DIR = $(shell pwd)/../../third-party/qthread

So, it can go as well.

While here, I also got rid of the unreferenced BINUTILS_GOLD_DIR
definition in the llvm Makefile, after checking with the author that
there was no expectation it would be needed in the future.
Change printchplenv to show uname on --debug
Merge pull request #1022 from Kyle-B/kb-printchplenv-tweak

Change printchplenv to show uname on --debug
Update future based on Brad's comments.
Adding one typeselect future and one test showing its pointless

twoTypeSelects.chpl shows that the current implementation of
type select does not support multiple type selects in a single
Chapel program.  D'oh!  It's probably a five-minute fix to get
this working if one cared to.  By the time I'd written up the
description in the .future, it seemed like I also had the
solution.  But...

deprecateTypeSlect.chpl shows the syntax I'd prefer to use for
"type select" statements and was intended as a feature request
future; but it turns out to work.  So it raises the question
"Do we even need a type select anymore?"  Until someone argues
convincingly otherwise, my answer is "no, it seems like we
don't."
Merge pull request #1026 from bradcray/typeselect-futures

Adding one typeselect future and one test showing it's pointless

twoTypeSelects.chpl shows that the current implementation of
type select does not support multiple type selects in a single
Chapel program.  D'oh!  It's probably a five-minute fix to get
this working if one cared to.  By the time I'd written up the
description in the .future, it seemed like I also had the
solution.  But...

deprecateTypeSlect.chpl shows the syntax I'd prefer to use for
"type select" statements and was intended as a feature request
future; but it turns out to work.  So it raises the question
"Do we even need a type select anymore?"  Until someone argues
convincingly otherwise, my answer is "no, it seems like we
don't."
Merge pull request #1025 from lydia-duncan/paramFnFuture

Update future based on Brad's comments.
Merge pull request #1020 from gbtitus/simplify-3p-makefiles-beyond-gmp

Simplify third-party Makefiles.

This is a follow-up to https://github.com/chapel-lang/chapel/pull/1013,
which simplified third-party/gmp/Makefile{,.include}. That passed
nightly testing last night, so now we're doing the other third-party
packages.

First, in Makefile.include (or for llvm, Makefile,share), change the
ordering of the make(1) variable definitions to be generally:

  base and unique build dirs
  build dirs
  install dirs
  source dirs and files, if any
  lib dirs and files, if any

Second, these lines in Makefile were superfluous:

  <pkg>_ABS_DIR = $(shell pwd)
  <pkg>_INSTALL_DIR = $(<pkg>_ABS_DIR)/$(<pkg>_INSTALL_SUBDIR)
  <pkg>_BUILD_DIR = $(<pkg>_ABS_DIR)/$(<pkg>_BUILD_SUBDIR)
  <pkg>_DIR = $(<pkg>_ABS_DIR)

Because <pkg>_ABS_DIR isn't referenced anywhere else, they're equivalent
to:

  <pkg>_DIR = $(shell pwd)
  <pkg>_INSTALL_DIR = $(<pkg>_DIR)/$(<pkg>_INSTALL_SUBDIR)
  <pkg>_BUILD_DIR = $(<pkg>_DIR)/$(<pkg>_BUILD_SUBDIR)

But these latter two definitions of <pkg>_{INSTALL,BUILD}_DIR are
identical to the ones in Makefile.include, which is included here by
virtue of ../../make/Makefile.base being included at the top. So they
can go. And the first definition here is effectively the same as this
one that is already in Makefile.include:

<pkg>_DIR = $(shell pwd)/../../third-party/qthread

So, it can go as well.

While here, I also got rid of the unreferenced BINUTILS_GOLD_DIR
definition in the llvm Makefile, after checking with the author that
there was no expectation it would be needed in the future.
Fixing a typo pointed out by @thomasvandoren
Merge pull request #1028 from bradcray/typeselect-futures

Fixing an innocuous typo

pointed out by @thomasvandoren