Walk a tree of objects to find an object by name.

[sam-falvo]

This isn't a complete filesystem yet, but it's the core component for one.

+-------------------+
|                   |
|   +-----------+   |
+-->| ObjDir    |   |
    +===========+   |
    | parent    |---+    +--------+
    | children  |----*-->| ObjEnt |
    | walk()    |    |   +========+
    | dispose() |    |   | name   |---------> "name of directory or file"
    +-----------+    |   | object |----+
                     +---| next   |    |    +-----------+
                         +--------+    +--->| Obj*      |
                                            +===========+
                                            | walk()    |
                                            | dispose() |
                                            | ...       |
                                            +-----------+

STS would maintain a global pointer to a root ObjDir instance. This instance would refer to one or more children, whose names correspond to top-level filesystem handlers in TRIPOS (e.g., /sys would basically be an alias for the current boot volume, /sd0 would map to the first sd card unit, etc.). Subdirectories might include low-level device drivers, like /dev/sd/0 for raw access to the SD card interface, for instance. Also, /proc for process statistics, etc. You get the idea.

ObjEnt structures are not objects; they're just (next, name, object) associations maintained in a singly linked list. In this respect, the ObjEnt structure is an implementation detail exposed due to inadequate abstraction on the part of Obj structures (for now; expect this to get better in the future).

ObjDir is an instance of Obj, an abstract class of filesystem objects that cannot be directly instantiated on its own. It's not in this commit, but I'm planning on a RomFile implementation which is also a kind of Obj, but which provides actual file semantics (as distinct from directory semantics).

The walk method (objWalk in the code) is responsible for processing one or more name components and walking its own, localized namespace. If a resource is found, the remainder of the name is passed thereto, recursively, to complete the walk within its own context. Note how objDirWalk invokes objWalk recursively once an ObjEnt with a matching name component is found.

Directories MAY return themselves if walking "", but aren't required to. They MUST attempt to resolve a component if the path is non-empty. Files have opposite semantics. They MUST answer themselves if walking "", but MUST yield an error if an attempt is made to resolve beyond a file.

Other kinds of objects have their own unique semantics as well. For example, a reparse- or symbolic-link object would be responsible for manipulating the passed filename and commencing the walk all over again from scratch. (For this reason, I'd like to advocate against symbolic links until a proven need for them exists.)

Fixes #140