changed again for reasonable performance

first_glance.f to read in l_gamma (w/o hybrid).
Updated atom_sym.f, crystal.f, inpgen.f90, lattice2.f, setab.f, and
struct_input.f for "Examples sorted by Bravais lattice" on web-page.

It is tested with the Yb example from the homepage.

This is introduced to guarantee that inp.xml can always be validated
against the Schema file belonging to the right fleur version.

To transform the atom positions in atom_sym.f into the centered basis,
a variable (i_c) is passed through to indicate the type of centering.

r_inpXML included a call to setlomap. This subroutine has the side effect
to reinitialize ulo_der to a value according to the definition in the old
inp file. I removed the call to setlomap and included the missing other
initializations directly in r_inpXML.

Note that there is still a bug in the LO setup iff multiple LOs with same
l quantum numbers are defined for the same species. Fleur has the rquirement
that the LOs are ordered with respect to the l quantum numbers. This ordering
is not yet performed in r_inpXML.

For systems with multiple atom types there was a bug in r_inpXML.
This is corrected with this commit.

Also in this commit: Changed the order of the core states.

Note that there are still bugs.

From the commit message in the old git:

    Fixed bug in geneigprobl:

    The LAPACK routine ssyevr and similar routines expect the result
    array for the eigenvalues to have the length of the dimension of
    the matrix that it diagonalizes. The eig array that is used for
    this purpose only has the length of the number of eigenvalues
    that are supposed to be computed. This problem is fixed in this
    commit by introducing a temporary and large enough eigTemp array
    from which the eigenvalues are copied to the actual eig array
    after calculating them.

    Note that the bug that is corrected here actually showed up
    only sporadically in the deallocation of bkpt in eigen.F

to the 'old' one. Include that in "maxdist".

The correction implies a notification to the user.

At the moment film calculations cannot be performed without an explicit
enpara file. We want to overcome this by introducing reasonable default
vacuum energy parameters. However, in this quick fix the problem is simply
solved by generating an explicit enpara file whenever film calculations
are performed.

The error occured in line 172 and could be tracked back to a missing
initialization of rho in stden.

Also in this commit: Enabled reading in enpara in w_inpXML
iff it exists.

Note: With this fix the Cu film calculation can be started with
the inp.xml file. However, the results are not yet verified.

from stden (t) and cdngen (f) to allow calculating starting densities
for atoms without core states.

For very simple test systems fleur can now use the inp.xml file
as an input. Note, however, that the functionality is still
very incomplete. Therefore, preliminary fleur has to be invoked
with -xmlInput to make use of inp.xml.

Besides the feature incompleteness it is expected that there are
still some bugs in loading inp.xml. So far it is
only tested for Si and Fe. For Fe a small deviation from the
reference total energy is observed (0.03 mHtr), the magnetic
moments are off by 0.003. The cause is yet unknown.

for centered lattices in atom_sym.f. If generators were given, atomid()
was wrong - corrected also in atom_sym.f. Some formatting of output
improved in atom_input.f, inpgen.f90, symproperties.f, and set_inp.f90.
Calculation of bbmat fixed in setab.f.

If the internal default enpara file was used it could happen that
index 3 of the qal array in eparas, line 125 was wrong. This can be
tracked back to a missing initialization of enpara%skiplo. I now
initialize this array in inpeig.f90 before default_enpara is called.
The bug fix is in analogy to the initialization of skiplo in
atom_input where an enpara file is generated by inpgen.

the coordinate system) and noangles=f (scale the lattice vectors). The
variable is passed from lattice2.f, where also settings for latsys='rho'
have been updated.

are now properly initialized.

The bug was introduced by the earlier fixing of the spn index
in the tuulo array: ae673d10

In broyden.F90 sometimes the error floating invalid occured when extensive
runtime checks were enabled. The error occurs in the line were the arrays
sm and sm1 are subtracted from each other.

The conjectured cause for this is that only a part of the arrays is really
used. Their size is larger. The part that is not used is never initialized.
So it may occur that subtracting the arrays from each other results in
an invalid operation in the part of the array that is not used.

We could not directly verify this conjecture. But reducing the subtraction
to the used part seems to cure the problem. We did that and additionally
initialized the local arrays to 0.0.