Git path directory, for adding transparent git support for datasets

A `.git` file can be created with content: `gitdir: <path-to-zFS-where-no-pdspdse-constraints-exist>` to keep all git data elsewhere. 

Another advantage of keeping .git data separate (DSFS transparently handling just a representative `.git` file) is that there can be a period of co-existence with both SCLM/Endevor/zOSChangeTracker managing libraries, and git doing it via DSFS.
The former group wouldn't need to add support for any extra special case members in a library (ex: members starting with `.`). 

How about this - PDS/PDSEs that need to be git-managed should have a member named $GITDIR, and it should contain the text `gitdir: <path-to-zFS-where-no-pdspdse-constraints-exist>`. `$GITDIR` is just an allowed name/alternative to `.git` which should actually have the above `gitdir: ....`
Create a new access layer `/dsfs/git/`, which is just a wrapper over `/dsfs/txt/` (and maybe `/dsfs/bin/`, if people want git-managed binaries), and this 'namespace' is where the clever git-handling / re-direction will exist.
This `/dsfs/git/` wrapper is preferred because it then means the majority of non-git text accessed via `/dsfs/txt/` wouldn't need to pay the performance penality of checking if it's a git directory.
Whenever anything is accessed via `/dsfs/git/` , DSFS transparently presents the `$GITDIR` file as the `.git` file, and then git the tool accepts it and looks for git info wherever gitdir: points to.

In summary, add the capability in DSFS to transparently process/present the PDS/PDSE member $GITDIR as `.git`. Then, regular USS file processing & git the tool will see that `.git`exists, and will work with the library as a git directory.