Include abstract syntax based on the thesis for FSOs

See https://edolstra.github.io/pubs/phd-thesis.pdf, page 91.

doc/manual/src/design/store/objects.md

@@ -9,6 +9,16 @@ A store object is the pair of
 ## File system objects
 
 The Nix store uses a simple filesystem model.
+
+    data FileSystemObject
+      = Regular Executable ByteString
+      | Directory (Map FileName FSO)
+      | SymLink ByteString
+
+    data Executable
+      = Executable
+      | NonExecutable
+
 In particular, every file system object falls into these three cases:
 
  - File: an executable flag, and arbitrary data
@@ -26,10 +36,21 @@ A bare file or symlink as the "root" file system object is allowed.
 This is close to Git's model, but with one crucial difference:
 Git puts the "permission" info within the directory map's values instead of making it part of the file (blob, in it's parlance) object.
 
+    data GitObject
+      = Blob ByteString
+      | Tree (Map FileName (Persission, FSO))
+
+    data Persission
+      = Directory -- IFF paired with tree
+      -- Iff paired with blob, one of:
+      | RegFile
+      | ExecutableFile
+      | Symlink
+
 So long as the root object is a directory, the representations are isomorphic.
 There is no "wiggle room" the git way since whenever the permission info wouldn't matter (e.g. the child object being mapped to is a directory), the permission info must be a sentinel value.
 
-However, if the root object is a file, there is loss of fidelity.
+However, if the root object is a blob, there is loss of fidelity.
 Since the permission info is used to distinguish executable files, non-executable files, and symlinks, but there isn't a "parent" directory of the root to contain that info, these 3 cases cannot be distinguished.
 
 Git's model matches Unix tradition, but Nix's model is more natural.