ignore emacs backup files in .gitignore
initial changes to get webmachine running on yaws

Getting webmachine eunit tests to pass using yaws as the underlying web
server rather than mochiweb required the changes listed below. As of this
commit, though, more testing, especially with actual webmachine apps, is
needed. The only testing with a real app has been to generate a new
webmachine app to use yaws and ensure that its "/" page loads correctly in
a browser.

* Changed most direct calls to mochiweb modules to call a
  webserver-specific module instead, and added such modules for both
  mochiweb and yaws. Some calls to mochiweb modules remain, but only for
  calls to utility functions. Because of this, mochiweb is always treated
  as a dependency.

* Modified rebar support to add a rebar.config.script file to manage
  dependencies. To use yaws, users can set the OS environment variable
  WEBMACHINE_SERVER=yaws before running rebar to build or test
  webmachine. The rebar.config.script file looks for that environment
  variable to know whether or not yaws should be added as a dependency.

* Modified the wm_reqdata record type to add a field containing the name of
  the webserver-specific module to use for web server operations. There are
  a few places where this information isn't available; in those spots, none
  of which appears to be performance-critical, the code checks the OS
  environment for the WEBMACHINE_SERVER variable to determine the right
  webserver-specific module to use.

* Modified the new_webmachine.sh script to accept a -s option allowing the
  user to specify yaws as an alternative web server. If no option is
  supplied, mochiweb is used. Also modified a few of the application rebar
  templates to use a new {{webserver}} variable, including the start.sh
  template which now sets the WEBMACHINE_SERVER OS environment variable.

* Note that currently if you try to run "rebar eunit" when using yaws and
  without setting "skip_deps=true", the yaws tests will fail. This is a
  problem with yaws that I'll have to fix in the yaws repository.

With these changes, yaws can be used only as an embedded web server, but
more changes could be useful to allow webmachine to treat yaws as an
included application, or to allow an existing yaws application to use
webmachine as a yaws appmod or yapp.
Fix yaws include path.
improve new_webmachine.sh support for yaws

Add a rebar.config.script template to priv/templates that changes the
webmachine dependency for apps created by new_webmachine.sh to the
vinoski/webmachine fork if yaws is the selected web server.

Add a new variable webserver_app to priv/templates/wmskel.template to allow
the dependencies in a new webmachine application's .app file to be set
properly for the chosen web server.
Merge pull request #2 from cmeiklejohn/yaws

fix yaws includes to not use absolute paths
use the correct web server name in webmachine error messages
conditional compilation for webmachine_yaws module

To use this webmachine fork with mochiweb, the webmachine_yaws module must
compile successfully if no yaws code is available. Use rebar.config.script
to inject a WEBMACHINE_YAWS define when the OS environment variable
WEBMACHINE_SERVER=yaws is set. If this define is not set, webmachine_yaws
compiles to an empty module.

Also modify the Makefile to set the WEBMACHINE_SERVER OS env var when
invoking rebar.
remove urlsplit_path/1 from webserver-specific modules

The code just calls urlsplit_path/1 from mochiweb regardless of which web
server is being used (using mochiweb essentially as a library app), so no
need for webserver-specific versions of this function.
no need for rebar.config.script in priv/templates

The rebar.config.script file was added to dynamically modify the
rebar.config for new_webmachine-generated apps if the chosen web server was
yaws. The modification would clone webmachine from this fork rather than
from the original basho repo. But with commit 21b9f4, this fork now works
correctly for both mochiweb and yaws, so now rebar.config just clones this
fork unconditionally.
use mochiweb for parsing cookies and query strings

Rather than requiring webserver-specific modules to supply parse_cookie and
parse_qs functions, just use the ones supplied by Mochiweb. Thanks to
@Vagabond for the idea.
switch to using Yaws new dispatch module feature
enhancements to webmachine_yaws module

In the webmachine_yaws module, handle more config options and set the value
for the Webmachine "Server" HTTP header.
switch to Yaws master branch to pick up dispatcher support
minor app.src template fix
Validate Content-MD5 when present, with optional resource callback.
Capture the request body when streaming for MD5 validation.
Add generic error rendering routine to simplify internal decision responses.
correct edoc
BZ1293: Fix filter_by_resource to handle the 4-tuple format that includes a predicate fun.
fix resource filtering in host-based dispatch rules

It looks like webmachine_router:remove_resource/1 never worked on
host-based dispatch lines because it was attempting to match {Host,
Path}, instead of {Host, [Path, ...]}.  This patch changes the filter to
delve into those per-host dispatch lists to apply the filter correctly
there as well.