Merge pull request #4 from leutloff/master

Merge in several fixes from leutloff.

- For compatibility between different Boost versions
- Cleaning up some defines related to MSVC warnings
Added makefile for easy *nix install, fixed compilation errors.
Fixed one example and asio 1.48+ compilation error.
Merge pull request #5 from griwes/master

- Fixed compilation errors on Boost 1.48+.

- Fix fcgi asyc_echo example.

Kindly contributed by Michał Dominiak (https://github.com/griwes).
* Corrected boost version number for introduction of shutdown_service() (it was introduced as a private pure virtual method to boost::asio::io_service::service in version 1.47.  io_service::service is used as a base class for cgi/fcgi services...)
* Corrected boost version number for change from system_category (data) to system_category() method, which was a breaking change introduced in boost version 1.44
* Corrected <= to >= for shutdown_service() and system_category().
* Added boost version check for references to system_category to system_category() for win32_acceptor_service_impl.hpp and request_acceptor_service.hpp.
The binary 'and' bitwise operator being auto-evaluated as bool was not having the behavior the authors expected for parse_cookies and parse_form_only because these enumerations are not single bit values (i.e. 1,2,4,8,16) but a combination of single bit values.  As a result values were evaluating to true for the expression when not expected, resulting in exception behavior.  This has been fixed by explicitly comparing against the specified values after the bitwise 'and'.
* This is a work-around for a completely broken implementation. Specifically, thefunction call stack looks like:

    fcgi_request_service<Protocol>::handle_begin_request_header ->
    fcgi_request_service<Protocol>::parse_post_vars ->
    request_base::parse_post_vars ->
    form_parser::parse

Form parser explicitly states in documentation that valid form encodings are application/x-www-form-urlencoded, and multipart/form-data.  I am not familiar enough with HTML forms to know if this restriction is legitamite for html forms or not.  However, it is an invalid restriction for HTML POST in general, as long as the mime type is at least IANA registered (http://www.iana.org/assignments/media-types).

The code change is to allow POST of any (presumably IANA registered) mime type.  If the specific service implementation doesn't want to except it, then it can always return an error, but the library aught not prevent the server from accepting valid mime types, even if the server implementation hast to parse it manually.

(This problem was discovered when attempting to implement a RESTful service which accepts GET/POST for application/json)
Merge pull request #1 from benmccart/master

Three changes to fixes compilation/bugs