elaborate mission statement

gathered my thoughts around LispEA's purpose and character
to elaborate a more well-defined mission-statement
(so that visitors won't find a faceless project).

TODO: investigate generating README.md from meta/brainstorm.org
merge mission statement from master into dev

working on improving inter-branch development flow —
pull good commits from stable upstream where possible.
established spec/impl/inst module structure

TLDR: the Specification shall generate an Implementation
that can Instantiate the Specification.

trifurcated project into three aspects against we can develop more
focused behavior. in particular, i've set apart a Specification
("spec") aspect that will define abstract, platform-neutral
descriptions of the EAI patterns and their behaviors (e.g. "Message"
or "Canonical Data Format" or "Detour") — versus an Implementation
("impl") aspect that will describe how to instantiate the specified
patterns within a technology-constrained platform (e.g. "Linux" or
"JVM" or "Python"). Finally, the Instantiation ("inst") aspect will
capture specific realizations of the implemented specifications
(e.g. "LispEA examples" or "my firm's integration project" or
"awesome use-case submitted by our #1 LispEA fan") — in part to
document compelling proofs-of-concept, but also to provide a
deployment management mechanism.
Maven'ize project object model

selected Maven as our build/test tool. it's sort of overkill at the
moment versus Makefiles — however i've grown fond of its declarative
style, and it will facilitate complex integrations down the road
(provided i can keep out of its way). JVM integration for Lisp
(via Clojure) will probably prove easier, too. of course, in the
spirit of integration, i'll probably want to support alternate
competing buildsystems — however for now, Maven covers our bases.

[1]: http://www.ning.com/code/2011/03/building-non-java-stuff-with-maven-and-friends/
rename Maven modules

previously i'd just echoed the code name in the module name,
so i expanded them to more human-friendly names
(e.g. spec → Specification, impl → Implementation).
add parent POM to build child modules

configured a parent Maven project to build each of the three
child projects (spec, impl, inst). this makes it easier
to step back and build "everything" from the project root,
while retaining individualized settings for each sub-project.

[1]: http://books.sonatype.com/mvnex-book/reference/multimodule-sect-simple-parent.html
ignore emacs backups
elaborate project workflow and history policy

outlined the project's development workflow and disclaimed any
warranty of sandbox branch history.

[1]: http://nvie.com/posts/a-successful-git-branching-model/
[2]: http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing
[3]: http://lwn.net/Articles/328438/
merge project workflow and history policy