Work in progress example of using noop mode

A few people I've spoken with have mentioned the auditing usecase, ie.
knowing when something changes. This example shows using noop mode and a
entertaining shell script to provide a useful auditing tool for security
group changes.
Add full example for auditing usage of AWS module
Add audit example to examples homepage
Correct URL path for audit example
Merge pull request #36 from garethr/audit-security-groups-example

Audit security groups example
include mention of using IAM instead of ENV for access
(maint) add .idea/Gemfile.local to .gitignore
(doc) Add guidelines for providing contributions

* Thanks to @mhaskel for providing the basis of this
* Add `rake test` command
* Add metadata validation
* Add section about conversations around Pull Requests
Merge branch 'add-contributing-file'

* add-contributing-file:
  (doc) Add guidelines for providing contributions
Add waiter for instance_terminated

 - Since the destroy example wouldn't previously execute successfully in
   a single run, this demonstrates using wait_until to allow for working
   around the dependencies that require multiple runs to delete.

   I think doing this, while it slows deletes down, is worth it. I
   don't think we should wait everywhere, the parallelisation of
   everything coming up at once is too useful in my view. Worst case we
   could make this toggleable with a shared param.
 - Note that destroy.pp was also modified to use the notification arrow
   to ensure the proper ordering.  The current code does not have a way
   to properly order resources being torn down with ensure => absent,
   given that would require extra API roundtrips to be more aware of
   dependencies.
Simplify tests for create / destroy

 - puppet-sg is a leftover from previous code, and is not used by any
   instances, so remove it
Merge branch 'delete-in-one-go'

* delete-in-one-go:
  Simplify tests for create / destroy
  Add waiter for instance_terminated

  closes #27
(fix) Order independent ingress insync detection

 - Previously, it was possible to trivially generate spurious change
   notifications when the specified order of ingress rules inside a
   manifest did not match the order returned by AWS.  AWS always
   returns an ordered set of ip_permissions, first by protocol, then by
   port.  Since the conversion to group authorizations is lossy,
   segregate and individually sort those rules by group name.
 - Verify with an additional acceptance test that orders ingress rules
   within a manifest differently than what AWS returns, which would have
   previously caused such change notifications.
 - To support scanning Puppet apply output, it was necessary to change
   from system() to Open3.popen2e, and PuppetManifest.apply was updated
   to return a hash with the output lines and exit_status rather than
   simply returning a true / false success value.  Several callsites
   were updated accordingly.
Merge pull request #38 from Iristyle/fix-ingress-insync-detection

(fix) Order independent ingress insync detection
Sort security_group ip_permissions

 - In CI, a new failure occurred as a result of code
   introduced in the previous commit to order security
   group ingress rules as specified in a manifest, in the
   same manner as those returned as ip_permissions by AWS.
   It would appear that Rubys sorting algorithm doesn't
   necessarily match the behavior of AWS.  To ensure that
   the two sets are sorted identically, perform the same
   sort operation on the AWS returned rules.

   By normalizing the sort operation, the code is more
   resilient to AWS ordering, and generally future-proof
   should that behavior change on the AWS side.
Allow changing ingress rules after security group creation

* Updated the acceptance test to check both that rules are added
* and that rules are deleted
Merge branch 'allow-changing-ingress-rules'

* allow-changing-ingress-rules:
  Allow changing ingress rules after security group creation
  Sort security_group ip_permissions

  closes #33