Fixes #476 - Adds missing location details

- Adds keywords, service areas, and wait times fields to location
details template.
- Adds categories hierarchy styles.
- Adds service_areas template.
- Performs miscellaneous ruby style guide formatting.
- Adds location details specs (keywords, service areas, and wait times).
- Arranges location details spec checks in order they appear on details
page.
- Adds/edits description section titles for location and service.
I'd prefer to stop using this pattern, please. This is one of the areas I'm planning on refactoring, so the existing code can be cleaned up later, but any new partials we add should adhere to a better pattern. The way the `component/detail/template` is set up, it behaves very much like a method that takes parameters sent from another partial. That kind of logic is best kept out of the view. If there is a need to DRY things up, that logic belongs in a helper method. However, care must be taken to not make things so DRY that they become cracked. Damp is better than cracked and hard to read and understand.

In the details view, each section represents a different field, and it's possible that one might want to style or mark up some fields differently. By using a template, it makes it harder to customize a particular field. The other problem with this approach is that every time the page is rendered, each field goes through the same logic, even though that logic will never apply to certain fields. It would be faster to render the non-array fields (like Audience, Eligibility, Fees, etc.) directly, than have the code go through a conditional first.

In this instance, the best practice would be to have a separate partial for each field, each with its own custom markup, like the [languages partial](https://github.com/codeforamerica/ohana-web-search/blob/master/app/views/component/detail/_languages.html.haml). This way, there's only one place where you need to look to understand what a partial is rendering. With the existing template, there is too much thinking involved. You have to go to the `_body` partial, then make a note of the local variables that were sent to the `_template` partial, then keep track of those variables in your head while reading through the multiple conditionals, then think some more about whether or not the field is an Array, assuming you know off the top of your head what kind it is.

Also, any new content we add should make any user-facing text customizable. So, the `h1` for these new fields should be added to `config/locales/en.yml` and referred to in the partial with the `t()` method. For the Service fields, I think a good name for the key would be `service_fields`. So, it would be something like this:
```
en:
  service_fields:
    eligibility: 'Eligibility'
    fees: 'Fees'
```
In the view, you would use `t('service_fields.fees')`.
Please maintain alphabetical order within `en.yml`.
Thanks!