[File API: FileSystem] Path restrictions and case-sensitivity

I'd like to bring back up the discussion that went on at [1] and [2].

In particular, I'd like to propose a minimal set of restrictions for
file names and paths, punt on the issue of what happens in later
layers of the API, and discuss case-sensitivity rules.

For the sandboxed filesystem, I propose that we disallow only:
	* Embedded null characters [will likely break something somewhere]
	* Embedded forward slash (/) [it's our delimiter]
	* Embedded backslash (\) [will likely confuse people if we permit it]
	* Files called '.' [has a meaning for us already]
	* Files called '..' [has a meaning for us already]
	* Path segments longer than 1KB [probably long enough, and I feel
better having a limit]
...and explicitly support anything other than that.  I'm not proposing
a maximum path length at this time...perhaps we should just say "MUST
support at least X" for some large X?

Regarding case sensitivity: I originally specced it as
case-insensitive-case-preserving to make it easier to support a
passthrough implementation on Windows and Mac.  However, as
passthroughs have turned out to be unfeasible [see previous thread on
path length problems], all case insensitivity really gets us is
potential locale issues.  I suggest we drop it and just go with a
case-sensitive filesystem.

	Eric
	
[1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1031.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0704.html