make NoSync more effective

[seebs]

The database init and grow operations still used fsync even when
NoSync was set, on the grounds that these operations are comparatively
rare and it makes sense to want them to be more reliable even at
some marginal cost in speed.

But if you're doing tests on something which happens to use
boltdb lightly, so it creates databases but barely touches them, this
can result in hundreds and hundreds of fsyncs, possibly in parallel,
and that becomes expensive.

Worth noting: Yes, it's intentional that the grow() case is using
db.file.Sync() rather than fdatasync(). On some platforms, fdatasync()
may not cause filesystem metadata updates to get flushed, just raw
file data block updates. We optimistically hope that (File).Sync() will
do the right thing.

[missinglink]

semi-related: #290

[seebs]

If it matters, I did wave these changes at Ben Johnson before submitting them. I was originally going to change the db.file.Sync to fdatasync for consistency, but apparently the not-identical-on-some-platforms was itself intentional.

[ptabor]

1. I can imagine db.grow syncs can be expensive when operating on small (<AllocSize) databases.
   Are the init's worth the change as well ?

2. Why db.NoGrowSync flag is not sufficient to cover the Initial grow syncs ?

3. How about having the InitialAllocSize flag that determines the file size after the creation ?