feat: add single message path

[apetro]

Adds paths for viewing just one message, identified by id.

• /admin/message/{id} will view the message regardless of audience
• /message/{id} will view the message iff the message is available in the context of the request (so, considering who is asking, current date vs begin and end dates, etc.)

Why? To bootstrap idiomatic error handling in this Spring Boot microservice, namely

• trying to view a non-existent id should yield 404 NOT FOUND
• non-administratively trying to view a message you're not in the audience for should yield 403 FORBIDDEN

What this demonstrates:

• Controller returning null automagically is 404 NOT FOUND. (Not true! Moral of story is always ensure your unit test fails before it succeeds, otherwise maybe you forgot to @Test annotate, as I did.)
• Controller throwing automagically is 500 unless the exception is annotated (as the custom exceptions here are), then it's whatever the annotation said (here, 403 FORBIDDEN or 404 NOT FOUND).
• Domain exceptions can be generated down in the Service layer and beyond where they're really happening, let them percolate up out through the Controller, it's all good.

@ResponseStatus(value = HttpStatus.FORBIDDEN, 
  reason = "Requesting user not in audience for requested message")
public class UserNotInMessageAudienceException extends RuntimeException {

Tradeoffs navigated

Explored not using Exceptions to model errors out of the Controller layer. That wasn't much fun. SpringWebMVC really "wants" to use annotated Exceptions for this.

---

Contributor License Agreement adherence:

• This Contribution is under the terms of Individual Contributor License Agreements (and also Corporate Contributor License Agreements to the extent applicable) appearing in the Apereo CLA roster.

---

Definition of Done

• Documented
• Fails gracefully
• Tested
• Secure
• Adds no defects
• Shippable. Path is clear to promote to production
• Maintainable
• Configurable
• Readable
• Validates and sanitizes user input
• Styled (Google Style)

[coveralls]

Coverage increased (+0.3%) to 61.25% when pulling 857268f on service-one-message into 9feae9e on master.

[coveralls]

Coverage increased (+11.3%) to 72.187% when pulling 195c7ea on service-one-message into 4370efa on master.

[davidmsibley]

This exception will throw an exception if asOfWhen is null

[Doug-Reed]

This will fail with the new refactored filter structure. Let's merge #49 first, and then fix this with the new structure.

[apetro]

Intend to, in a new branch off of master, rebase these changes off of latest master to yield a clean PR. Will close this PR in favor of that when it's available. Will reset this PR's branch to that new branch, effectively "rebasing", when that is ready, thereby keeping the history of this conceptual branch in this single PR.

Pushed the new clean-one-msg branch, and cut over to it.

[davidmsibley]

Could the new custom exceptions be checked Exceptions rather than RuntimeExceptions? Runtime exceptions lead to not so funtime surprises.

[apetro]

I'm willing to give on this, but I thought RuntimeExceptions rather than checked exceptions were idiomatic in the context of the Spring framework. As I recall Rod Johnson's book waxed poetic on this point.

(Discussed f2f. Team consensus is regardless of whether RuntimeExceptions might be in the spirit of Spring Framework idioms, here use checked exceptions.)

(This is one of those moments where I'm entirely convinced I'm right to use RuntimeException, yet the marginal value in being correct is negligible (as it sometimes is!), so quite happy to bend to team consensus.)