Squashed commit of the following:
(1) commit 98ca3306f6ce9a3b2c2b9e75eb6a2fbdb6c8ad76
    Date:   Tue Sep 9 15:56:33 2014 -0300
(2) commit cfad9fc85147a7049fbc72debd80c0599f0d65f6
    Date:   Tue Sep 9 15:43:21 2014 -0300
(3) commit 6b345261ff6250a00c5f3d11278370cd6515f263
    Date:   Thu Sep 4 14:46:26 2014 -0300
(4) commit c9e307d46829e778728069ace1dd5c32766fbfb8
    Merge: f28176b 9e53959
    Date:   Wed Sep 3 11:48:11 2014 -0300
(5) commit f28176beff77e7d6541790846da529a5fed4cf19
    Date:   Wed Sep 3 11:38:55 2014 -0300

Tasks done and checked:
  (*) Smat created in garcha_mod.
  (*) int1 stores the overlap matrix both in Smat and RMM(M5).
  (*) Replace the usage of RMM(M5) for Smat in all* subroutines.
      (see notes).
  (*) Bug fixed (RMM13).

Notes:
  (+) The usage of RMM(M5) as FockMat still remains in the following
      subroutines: SCF, SCFop, TD. Also in: dip2, int3G, int3lu,
      predictor (which never used it as Smat).
  (+) Each call to int1 checks if Smat is allocated and if it is not,
      then it allocates it. Though this method works, it would be
      better to allocate Smat and other related matrixes at lio init
      or similar initialization subroutine.
  (+) RMM(M5) is still calculated by int1 and used by the essl option
      (isn't this obsolete?) and by the magma implementation (which
      I understand has not been completed, so it should be adapted
      by the person in charge of that).

Future Tasks:
  (-) Take the transformation matrixes that come from S decomposition
      or diagonalization (that is, Lmat, Umat and inverses) and put
      them in garcha_mod. Adapt subroutines to take advantage of this
      (example: program a TransformFock(M,Fock) that transforms fock
      'from AO base to MO base').