Intel had the bright idea to name their OpenMP command line flag

  -openmp

which of course cannot be distinguished from

  -o penmp

It seems they also realized this and now also allow -fopenmp or -qopenmp
as flags. Due to commit 2121b2e5 the autodetected -openmp was now
appended into the linker command line at the end, causing all C programs
to be named "penmp".

Fix by trying the -fopenmp, -qopenmp flags before -openmp in the
Fortran compiler flag detection m4 macro.

Rewrote the perl-script for the dependency generation to also accept
input file names from stdin, in order to avoid excessively large
argument lists.

This is a squash of the following cherry-picked commits from master that
correct some issues with the elpa.spec file:

  5c548fe6
  8285d13b
  b483df9b
  722ef865
  6e973ae5
  1acbcf5d

The actual reason for the linker problems was that the Fortran libraries
where listed before the object files, by modifying the _LINK automake
variables. The proper way to do is of course to add the necessary
libraries after the object files by appending them to the _LDADD
variables.

As the MPI module was not responsible for the linker problems it is now
used by default, unless explicitly switched off with

  --disable-mpi-module

Also, the C test programs that had these linker errors where previously
not compiled in the OpenMP case, for no obvious reason. Now they are
also included there.

For some strange reason this causes linker errors on _some_
openSUSE_Tumbleweed installations..

Apparently in some compiler/MPI combinations (gcc with impi 5.1.3) the
identifier 'mpi_status' is defined and exporeted in their MPI fortran
module and it is thus not allowed to name one of your local variables
also 'mpi_status'.

The confusing error message I got was

  ../src/elpa2_compute.F90:5780:37:

                  call mpi_wait(ireq_hv,mpi_status,mpierr)
                                       1
  Error: Invalid procedure argument at (1)

even though everything seemed to be defined correctly

Some people had problems finding the ELPA email address, thus
is is clearly specified here

The subroutine solve_tridi has NOT been shifted from the private
module "elpa1_compute" to the public module elpa1_auxilliary.

Instead, a wrapper function solve_tride has been introduced, which
calls (via Fortran module association) the private function.

This does what it is supposed to do, but should be cleaned up at
some time. Public functions (interfaces) should be implemented in
a public module

These functions were made private with ELPA releases 2016.05.001
and 2016.05.002, but they should be public