Careful object writing..

I just pushed out the commit that tries to finally actually write the sha1 objects the right way in a shared object directory environment.

I used to be lazy, and just do "O_CREAT | O_EXCL" on the final name, but that obviously is not very nice when it can result in other people seeing objects that haven't been fully finalized yet.

So now I do it "right", and create a temporary file in the "top" object directory, and then when it's all done, I do a "link()" to the final place and unlink the original.

I also change the permission to 0444 before it gets its final name.

Two notes:

 - because the objects all get created initially in .git/objects rather 
   than in the subdirectory they get moved to, you can't use symlinks 
   to other filesystems for the 256 object subdirectories. The object 
   directory has to be one filesystem (but it doesn't have to be the same 
   one as you actually keep your working ddirectories on, of course)

 - The upside of this is that filesystem block allocators should do the 
   right thing. Instead of spreading the objects out (because they are in 
   different directories), they should be created together.

Anyway, somebody should double-check the thing. It _should_ now work correctly over NFS etc too, and everything should be nice and atomic (and with any half-way decent filesystem, it also means that even if you have a system crash in the middle, you'll never see half-created objects).

NOTE NOTE NOTE! I have _not_ updated all the helper stuff that also write objects. So things like "git-http-pull" etc will still write objects directly into the object directory, and that can cause problems with shared usage. Same goes for "write_sha1_from_fd()" that rpull.c uses. I hope somebody will take a look at those issues..

Anyway, at least the really core operations should now really be "thread-safe" in a shared object directory environment.

		Linus