store: add locking around cas diskv

[sgotti]

As a reminder (I'll post patches when the various #392, #393 lands) there's the need for some locking around cas diskv stores. Now they are needed to avoid multiple processes writing the same image and image manifest to the store and also when (in future) a delete functions will be added to the store.

This is my proposal:

• Do not lock on basic diskv funcs like Read, Import etc... as there's the need to write on multiple diskv stores inside the same lock. For example in WriteACI (after cas: Add Imagemanifeststore, save ImageManifest on WriteACI and ad GetImageManifest function. #392) there's the need to write the ACI and the image manifest inside an unique lock.
• Fine grained locking on the single key of the diskv store with single writer/multiple reader pattern.
• To avoid deadlocks do not lock the diskv key inside the db locks or vice versa. Peraphs choose a lock order (always first lock the diskv key before the db)
• As image and imagemanifest stores are tied together the image and imagemanifest for the same key should use an unique lock.

Some places where locking is needed:

• On WriteACI take a write lock on the key at the start and release it at the end.
• On ReadStream take a read lock on the key.
• On GetImageManifest (cas: Add Imagemanifeststore, save ImageManifest on WriteACI and ad GetImageManifest function. #392) take a read lock on the key

Functions like GetACI (#395) can call multiple times the DB functions and the diskv functions (like GetImageManifest) so if we want to avoid any problem we should take a global lock. Not doing this means that during GetACI loop an image or image manifest could be added or removed. I don't think this is a problem as this is checked and the error is handled.

[sgotti]

@jonboulle I'm willing to work on this after #362, #392, #393. Honestly I already have some patches but, opening a PR will mean a lot of rebasing between this and the other PRs. Just let me know what you'll prefer. Tnx!