fix: add permission checks to MemMapFs Open/OpenFile

[veeceey]

Fixes #150

Right now MemMapFs ignores file permissions completely -- you can chmod a file to 0 and still open/read it without any error. This makes it pretty much impossible to use MemMapFs for testing code that cares about file permissions.

This PR adds basic permission checking:

• Open() checks read permission bits (0444) before returning a handle
• openWrite() checks write permission bits (0222) before returning a handle
• Create() now defaults to 0666 permissions, matching what os.Create() does
• Stat() bypasses the permission check (uses internal open()) since real stat(2) doesn't require read permission either
• Auto-created parent directories in registerWithParent now get 0755 instead of 0, so they stay accessible

The permission model is simplified -- it checks any read/write bit being set rather than doing full uid/gid owner/group/other matching. This keeps things straightforward while still catching the common case of chmod 0 or testing read-only vs write-only scenarios.

[CLAassistant]

All committers have signed the CLA.

[veeceey]

Test Results

Full test suite passes:

$ go test -count=1 ./...
ok  	github.com/spf13/afero	4.358s
ok  	github.com/spf13/afero/mem	0.156s
ok  	github.com/spf13/afero/tarfs	0.454s
ok  	github.com/spf13/afero/zipfs	0.603s

New test TestMemMapFsPermissionChecks covers:

$ go test -v -run TestMemMapFsPermissionChecks ./...
=== RUN   TestMemMapFsPermissionChecks
--- PASS: TestMemMapFsPermissionChecks (0.00s)
PASS

Verified manually:

• Creating a file gives 0666 permissions (matching os.Create docs)
• Chmod to 0 then Open -> permission denied
• Chmod to 0444 then Open for read -> ok, Open for write -> denied
• Chmod to 0222 then Open for read -> denied
• Stat works regardless of permissions (matching real stat behavior)

[veeceey]

hey, any thoughts on this?