Maid 271 Windows Permissions

This patch will convert Posix ACLs from MetaData to a windows ACL list and then verify access privileges to the appropriate functions. Since every file/folder in drive is currently marked as read/write to the owner only, this patch will restrict access to drive to the user that mounted in windows. No other user will be able to view or modify the contents of the drive. This patch is pretty large, and might need to be held off until drive_v2 is merged into next (talk to Prakash).

I would also like feedback on the error handling. I decided to throw exceptions if a windows function failed - this should only happen in extreme circumstances (bad parameter or out-of-memory, etc.). expect<> might be preferrable here, but its not available, and the error cases should truly be rare.
If there's any doubt, I guess we should leave the checks as they are.

Having said that, I'd expect either `sender` or `file_name` being null to be a bug in Eldos' code (and they're reasonably quick to respond to bug reports from what I've experienced).  I can't see how any of the callbacks can validly be called if `sender` is null since that should be the object doing the calling, and I don't know what we'd be expected to do in a callback if the `file_name` is null since the only other way for us to get the file name is to retrieve it from a previously-populated `UserContext` in the `CbFsFileInfo` (the use of which is optional).

Also, we'd probably have already experienced such an issue since we didn't previously do checks for null.

If you decide to leave the checks in place, is it worth considering adding asserts before the checks so we can't miss an instance of one of these being null and hence we can bring it up with Eldos?

All in all, I'm comfortable with whichever you choose.  Leaving them in is definitely safer and probably makes more comfortable reading for an external dev reading our source code.