New "Topic" model

Wally::Topic
  #topic(path) looks up a descendant topic
    returns self when path matches
    returns nil without consulting children when path is not a match
    finds descendent topic
  #ensure_descendents(path) acts like mkdir -p for topics
    returns self when path matches
    extension in path is ignored
    with a direct child path
      returns a newly instantiated child topic
    with non immediate descendent path
      creates new topics
      already existing descendent topics are added to
Initial code for importing and retrieving project artifacts

Project
  #import_content(path, io) imports generated project artifacts
    a first level .feature
      adds the feature to the project
      adds a topic for the feature
      links the feature with and the topic
    a nested .feature
      adds a topic for each parent element in the feature path
  #topic(path) looks up a topic by path
    finds top level topic
    finds nested topics
    returns nil when no topic for path is found
    finds topics using :'s or /'s for separators
Support for pushing project artifacts from posted .tar.gz of features directory.

This will allow things like non gherkin documentation files and navigation config files, etc..
Convenience method ParsesFeatures.parse
Support for importing project artifacts from posted tar.gz so that we can use more than just .feature files. E.g. markdown documentation and navigation configuration files, etc..
Introduced unit level testing for Application testing.

Don't like having to test every detail from Cucumber. Also, I like unit testing controller actions as a check that my controller actions don't collect logic that should live elsewhere..
Delete project via wally-client

Removed authentication for now. It seemed pretty crude appending a well known password as a request param. Does that offer much? Going with nothing right now until something better can be implemented.
Pushing and deleting now through wally-client
Hierarchical navigation

 Scenario: Navigate topic hierarchy
    Note: Topics are listed alphabetically by default
    Given I push the following features to project "foo"
      | Path          | Name      |
      | foo/a.feature | Feature A |
      | foo/b.feature | Feature B |
      | c.feature     | Feature C |
    And I visit the project page for "foo"
    Then I see the following listed in order in the project sidebar
      | Feature C |
      | Foo       |
    When I follow "Foo" in the project sidebar
    Then I see the topic page for "Foo"
    And I see the following sub-topics listed in order
      | Feature A |
      | Feature B |
    When I navigate into the "Feature A" sub-topic
    Then I see the feature page for "Feature A"
Tweaked feature docs
Feature pushing,deleting, etc... now through wally-client.

See features/wally-client/*
Topic#<=>(other) comparison operator
    a topic with a lighter sort weight is before one with a heavier sort weight
    a topic with a sort weight is before a topic with no sort weight
    two topics without an explicit sort weight are ordered by name
Display topics ordered by natural sort order
Topic ordering and renaming via config hash (i.e. parsed .nav file)

Wally::ProjectCustomizer
  ignores config entries with no corresponding topic
  topic renaming
    "foo (Something else for foo)" renames "foo" to "Something else for foo"
    works on top-level topics with sub-topics
    works on sub-topics
  topic sort weights are set from position in config
    works with flat structure
    works with a mix of top level and nested
    works with or without .feature extension
    picks up sort weight for renamed topics
Feature: Customizing topic navigation with .nav file

  So that features can serve as good documentation,
  ordering can be customized by including a .nav file
  at the top of your features directory. Display names
  can be customized as well.
Delete all projects in before hook instead of after so that projects are still available for inspection after failed cuke.
Crude configuration mechanism with ability to suck in config from yaml file.

Wally::Config.work_dir
Eliminated obvious step
Scenario: Single cell data table

Then I see the data table as a list