LWRP focused rewrite

I was having some issues reverting values, so I started down a path to cache the defaults as they're removed and kept tweaking and tweaking and here we are.

I completely understand if you'd prefer to leave this as a separate fork, but I thought I'd offer it up and let you decide for youselves.

Rather than duplicate everything here, the best option is to skim over the updated usage section in the readme for starters, and then then continue below where I'll outline the less visible changes.

---

  - These changes address [#1](https://github.com/onehealth-cookbooks/sysctl.orig/issues/17) by way of the conclusion reached in this [Chef Bug tracker issue](https://tickets.opscode.com/browse/CHEF-5313). The result of trying to set an invalid or unsupported key is an explicit error explain that. The best way to handle this would be using the LWRP and something similar to `not_if platform_family?('freebsd')` to prevent the attempt to set keys based on platform.
  - They also address the caching issue mentioned above, allowing `:remove` to immediately return parameter values to their system default.
  - Everything goes through the LWRP, so if a config file is available values will always be persisted in the course of the chef run (with the ability to force the write sooner using `action :save`.
  - Support for flat keys i.e. `'vm.swappiness' => 20` and `vm: { swappiness: 20 }` render the same outcome
  - Fix issue where if key was removed from `node.sysctl.params` in a subsequent convergence, the value would be removed from the persisted file, but not unset from the server, violating the expected idempotent behaviour of cookbooks
  - Fix `whyrun?` support as it was claiming to support whyrun behavior and then changing kernel values in what should have been dry runs.
  - Split out BSD testing into a separate suite due to current suites using keys BSD does not support.

---

I've run the full test suite against this PR and it passes with two exceptions; the first is the integration tests for `fedora-20` which fails for me due to [this vagrant issue](https://github.com/mitchellh/vagrant/issues/2745) (but it passes once the suite is restarted), and the second is a foodcritic issue which I believe to be a false positive.

Happy to answer any questions you may have.