GitLab

This is a bit cumbersome, as it involves yet another abstract
intermediate type, but necessary due to language limitations.

We decided not to provide this information via the key/value store, but
rather to use the ftimings module for that.

@loh will take care to implement ftimings in the new API
@amarek wants to port the legacy API so that the old global module
  variables still contain valid values

The legacy API is has been (internally) ported to use the new interface.
The intent is that users of the legacy API do not have to change their
codes.

Next step is to completely adapt the .gitlab-ci.yml file

Still missing is the compatibility layer, currently it only compiles
when configure is called with

  --disable-legacy

Also, a more general solution to parameter passing via environment
variables would be nice.

Supports multiple indexes now, to be used for non-tunable 'parameters'

This attempt at a new, more flexible API for ELPA should hopefully
result in less ABI/API breaking changes in the future.

The new API features a generic key/value system for options that can be
extended without changing any exported symbols or function signatures,
so that new, optional features do not influence existing usage of ELPA.

We hope this makes life easier for users of ELPA - at least in the long
run when they migrated to this newest of ABI changes :)

Example usage (explicit documentation to be done in a future commit):

   if (elpa_init(20170403) /= ELPA_OK) then
     error stop "ELPA API version not supported"
   endif

   e = elpa_create(na, nev, na_rows, na_cols, nblk, mpi_comm_world, my_prow, my_pcol, success)

   call e%set("solver", ELPA_SOLVER_2STAGE)
   call e%set("real_kernel", ELPA_2STAGE_REAL_GENERIC)

   call e%solve(a, ev, z, success)

   call e%destroy()

   call elpa_uninit()