Updated handling of the git repositories

Hi,

The apply file and the amount of patches has grown too big, it is
getting harder to maintain, and to update to the new milestones.  I
changed the use of git in ooo-build a bit, in hope that it will become
easier ;-)

When you use --with-git switch from now on, instead of using git only as
a convenience tool to get the milestone updates faster, you can commit
directly to the 'master' branches of all the ooo-build repositories now,
and these commits will be actually used.  For the package maintainers
that do not use --with-git, nothing really changes, it will be still
possible to use the release tarballs from cgit; just from now on, we
have to tag master, instead of reusing the ooo/XYZABC_mG tags.  Petr
will take care of creating them.

If you use --with-git, you should pull -r now, and re-run ./autogen.sh
--with-git --with-tag=ooo330-m4.

And now how it works ;-)  When you specify --with-git among
the ./configure switches, you'll get the clones of the ooo-build
repositories in <ooo-build>/clone/ subdirectory.  Modules (vcl, sc,
sw, ...) are then linked to <ooo-build>/rawbuild/ subdir, and then the
entire <ooo-build>/rawbuild/ is copied to <ooo-build>/build/ooo330_mX/.
The assumption is that the developer develops either in build/ooo330_mX/
(using patches as until now), or in rawbuild/ (committing directly to
master), but never in both at the same time.

If you are among those who will want to work directly in git, rawbuild/
is your playground from now on - do

cd rawbuild/
./configure ...

and read the instructions.  Note, the '...' means you have to provide it
with most of the usual --with-system-* options ;-)  Another useful
option is --with-external-tar=<ooo-build>/src so that you don't have to
download the tarballs for the second time.

In rawbuild/, you can actually get into trouble due to the fact that we
have split the sources into several git repositories.  To make the work
with them more convenient, I created <ooo-build>/bin/g wrapper for git
commands that will operate on more repositories at the same time.  Eg.
to move a patch from patches/dev300/ directly to git, you can do

cd rawbuild/
# apply one patch to appropriate repos (can result in changes in more
# repos at the same time)
g apply ../patches/dev300/patch-name.diff
g status
g commit
# and now remove patch-name.diff from patches/dev300/apply so that it
# does not conflict when you use the patched scenario

All this is very new, so use on your own risk ;-)  Specifically, at the
moment, the master repositories are not really open for big commits, we
have to see first how it works, polish it a bit, etc.  Ideally, only
build-related stuff should go there for now.  Risky and experimental
stuff, as well as cws backports should stay as patches.

Also, be aware that no commit should introduce tabs for indentation in
the .cxx/.hxx files, I am happy that we got rid of them in the git
repos ;-)  I created a commit hook that will check that that is enabled
in the clone/ repos.

For the future work, I consider the rawbuild/ way a temporary solution,
hoping that we will really make the split build usable generally, ie.
that you'll be able to work on just one of the repositories, without
having to build everything else.

Regards,
Kendy