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.

It sounds like a helper method might be the way to go. From the CSS-side it's preferable to have these in a consistent HTML template, with permutations on the template easily identified. If they all have their own named partial it becomes difficult to know which partials need to be updated and which don't if the underlying shared HTML structure needs to change. I'd like to move more toward a Web Component model where UI components are a self-contained collection of HTML/CSS.

> 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.

Right now they each have a unique class name, so can be styled differently through that. The underlying mark up can be separated out for the ones that are different, as is done now, but it's preferable that the same HTML markup be shared.

> By using a template, it makes it harder to customize a particular field. 

Ideally, the sections would have underlying components defined through a CSS class and a shared HTML markup and if someone wanted to customized this they'd swap in a different component appearance by changing the class and possibly using a different underlying markup.

E.g. right now we have:

```
<section class="eligibility"><h1>Eligibility:</h1><span>None</span></section>
```

Instead we should probably add a component class to this, something like:

```
<section class="summary eligibility"><h1>Eligibility:</h1><span>None</span></section>
```

Then if someone wanted to customize this, they'd maybe have a different set of component styles they'd apply with:

```
<section class="summary-compact eligibility"><h1>Eligibility:</h1><span>None</span></section>
```

... that maybe was the summary but had less padding/margin and fit on one-line or something.

Additionally, they could due customizations to this specific component instance through the `.eligibility` class.

Anyway, I'm not sure what that looks like on the Rails side, but point is any re-usable UI chunk in the design should be isolated and have a shared HTML structure with other UI chunks that are same.