Style: Make whitespace changes
Feature: Add 'to_flattened_name_hash' to Settings

This method takes any hierarchical layout that a setting may have and returns
a one-dimensional `Hash` where the keys are the flattened components of the
setting's name hierarchy.

Example:

```ruby
Settings.new(settings: {
               my_setting: 'value',
               level_1:    {
                 level_2:    {
                   some_setting: 'hello',
                 },
                 body:       'gracias',
               },
             }).to_flattened_name_hash
  ['my_setting']                         => 'value',
  ['level_1', 'level_2', 'some_setting'] => 'hello',
  ['level_1', 'body']                    => 'gracias',
}
```

This could be used in multiple places such as displaying the settings via `to_s`
which is currently being run through `SystemEnvironment`, but it can also be
used for determining where in the YAML file that an encrypted setting needs to
go.
Refactor: Use the new to_flattened_name_hash

Instead of reinventing the wheel, we can derive things from the
`to_flattened_name_hash`.
Refactor: Change pre and post filters for secure and insecure

Now that we have `TranslateSecureKeysFilter`, we should be able to use it in the
post filter and allow all filters to be able to use the translated `raw_data`,
this means that these methods should now be chainable:

Example:

```ruby
my_settings.insecure.secure
```

There is a difference between things that actually _filter_ settings and things
that _convert_ settings.  Actual filters should be in the `prefilter` list,
items that translate should be in the `postfilter` list.
Tests: Fix spec that wasn't cleaning up after itself if it failed
Feature: When securing files, do not rewrite the entire file

Now, when running `chamber secure`, chamber will only rewrite the lines in the
settings files that correspond to the items being secured.

Additionally, any whitespace before the key, after the key and before the colon,
as well as after the colon and before the value, will be preserved.

This logic only concerns itself with the root key, I don't see this as being
a problem because if the value is the same, it doesn't really matter which
version of the encrypted string is put in its place, but I could see this as
having a chance of being a potential bug down the road.

The update to the `File#secure` method hasn't been refactored as much as I would
like, but I wanted to get it in the wild before I spent a bunch of time on it to
see if this is going to be a sustainable solution.

References #11