Windows, decoupling from Play2War, eb-update-version, + extras

Quinn,

I have a pull request for ya!  First off, great job creating a handy sbt plugin!  I found it to be 98% of what I needed.  This pull request contains the tweaks I needed for our use case.  Here's a breakdown of what I did:

Added support for Windows
-------------------------
There were several usages of `System.getenv(String)` which retrieves info available to the standard unix environment.  I changed these out for `System.getProperty(String)` to retrieve the JVM-provided equivalent information.  Now the plugin works great for us unfortunate souls who are shackled to the vile MS corporation.


Removed hard dependency on Play2War
-------------------------
Our team uses Lift, so the coupling to `Play2War` prevented use from using the plugin out of the box.  I have updated the code base to no longer depend directly on `Play2War`.  The benefit is now *any* war-producing framework can utilize this plugin.  The cost is any current users wishing to upgrade to this version now must tell the plugin what task produces the war file.  In particular, this line must now be added to the build file:

    ebAppBundle <<= Play2WarKeys.war,

I like it because it helps make this plugin useful to a broader user base, and I hope it's an acceptable change for your current users.


Added eb-update-version
-------------------------
This is possibly a duplicate of `eb-quick-update`, at least in its intent.  The `eb-quick-update` didn't work for us because it needs to connect to our EC2 instance via SSH.  Our network architecture doesn't easily allow us that access.  Instead, it is much more straight-forward to utilize the AWS API to tell Elastic Beanstalk to deploy the newly-uploaded application version.  Our use case is continuous integration.  The downtime is acceptable.  


Reads from System properties when ~/.aws-credentials cannot be found
-------------------------
Also due to our use case of continuous integration, our build process runs on a VM with an automated user.  Hence it doesn't make sense for us to find all VMs our build *might* run on and include an `.aws-credentials` file.  Passing the credentials as properties via the command-line is a much more reasonable approach.  The plugin still first checks for the existence of an `.aws-credentials` file.  In the case one isn't found, the fallback first looks at `System` properties for `accessKey` and `secretKey`.  The error message has been updated accordingly.


Updated readme to show how to utilize with Play2War OR Lift
-------------------------
Finally I updated the readme to reflect the usage of the plugin with Play or other non-Play frameworks.  For the latter, I also wrote it in `.sbt` format as a second example of how the plugin can be configured.  Other changes such as the aws-credentials properties and Changelog have been updated appropriately.

I hope you find these changes suitable for a merge for general consumption.  Let me know if I should make any changes to my contributions.

Again, thanks for putting your hard work out here for others to take advantage of!

**Joe Barnes**
Senior Software Architect
System Design Division
Mentor Graphics