Used (cabal init) to cabalize the project
Fleshed out cabal configuration with a skeleton!

`cabal init` tries hard to get the project into a good initial state but
needs a little further help to get entirely up to speed. Package
configuration will obviously continue to develop as the project grows, but
at this point we want to be able to exercise most of the cabal commands
successfully. We could even upload this to Hackage now, though it'd be sort
of annoying.
Initialized the sandbox and gitignored the config
Fleshed out an example usage of the library

The Example begins to show us the types and interfaces we'll need to
implement in order to make the library work nicely. It's kind of a stand-in
for a test suite at this point, but we'll get to that eventually.
Added Haddock comments to **/Parser.hs

Haddock is Haskell's (quite nice) integrated documentation system. It's used
to automatically generate documentation for all of Hackage and it's often
much nicer to read than plain code---better formatting, hyperlinks, the
whole nine yards.

Documentation is fascinating in Haskell since so much information can be
placed into the type signature. Often I try to only document the intent of a
function and let the type signature show you how to use it. More complex
signatures might deserve some doctests or specializations, but that probably
won't occur in as simple a library as this.
Created a first-draft implementation of Parser

Right now `Parser` defers defining its Monad using
GeneralizedNewtypeDeriving to pick up the instance from IO. Alas, since
we've only layered `IO` into Parser so far it has no way to fail except to
throw a runtime exception... That isn't the *worst* that could happen since
if you're looking for something in the environment and it just isn't
there... you're probably sunk for running the rest of your application and
might as well call it a day.

But the whole point of this library is that there's something better you can
do.
Added a (very minimal) HSpec test-suite

Test suites in Haskell are just separate cabal artifacts, compiled as
independent executables. They have completely independent configuration and
are only built if requested using --enable-tests. HSpec is a unified test
runner framework which supports both HUnit and QuickCheck, the two most
popular testing libraries.

I tend to use both HUnit and QuickCheck tests together, so it's important to
use a test runner like HSpec. If you don't like HSpec then Tasty or HTF are
other choices of test runners.
Added two unit tests demonstrating Parser behavior
Added a QuickCheck-style test as well

QuickCheck style tests are property tests--tests which are run over an
unknown set of test data which is randomly generated on the fly. This
creates a very different style of testing where the test writer must thing
about properties which hold over arbitrary data. This can be a *very*
powerful way of thinking about your code and it's one that Haskell supports
quite a lot.

For instance, the test added here checks that, for all names, if we store a
value in the ENV at that name and then get it back out using our Env.Parser
that the value is intact. To do this the property test randomly generates
100 names and values and perhaps the test for each one.

I don't think that's actually a super high value test---normally, I'd be
more interested in something like this when I suspect there might be edge
cases buried in the sea of random data. In this case, it serves more as a
placeholder and example.