gnulib now a subrepo

[Jordi Gutiérrez Hermoso]

tl;dr: make sure you have at least Mercurial 1.8 from now on,
otherwise, business as usual.

Following a discussion in #octave, we decided that saying "have you
updated gnulib?" isn't always the best thing to do, because gnulib can
change and leave us stranded in the middle in a broken state. Trying
to fix this, the hash of the gnulib revision is now versioned in each
hg cset in a subrepository. I currently set the gnulib revision to
84c3f9cf54eaa688c5a1a26925886535079a91de since that's what Kai Habel
reported was working.

If you're curious to know how it works, read on. If not, it should all
be handled automatically from now on *IF* you have Mercurial 1.8 or
later. If not, I'm not sure what will happen, but it probably won't be
pretty. Mercurial 1.8 isn't hard to obtain (even Debian stable has it
in a subrepo!) so I don't see any reason for anyone to be using an
older hg.

There is now an .hgsub file at the top-level directory that should map
the gnulib/ directory to its Savannah URL. Additionally, there is an
.hgsubstate file under hg control that tracks the gnulib revision that
is known to work with this particular commit. When we decide to update
the gnulib revision, go into the gnulib/ directory, run whatever git
incantations are necessary to update ("git pull" and perhaps "git
checkout $githash" should be enough), test that most things work, and
commit one directory above. hg will automatically update the
.hgsubstate file and this git revision will now be associated to this
hg revision.

If for whatever reason we run into a bad gnulib revision, we can use
this mechanism to update the gnulib revision to an earlier known good
revision. Just run "git checkout $known_good_revision" and commit in
the hg repo one directory above.

Hopefully this will help us with our random gnulib brokennes we've
experienced and can stabilise the gnulib situation.

HTH,
- Jordi G. H.