Display a list of conversations.

- This is part of a larger story to present conversations rather than
  individual messages. We chose to implement the list of conversations
  first, because this felt like the higher risk aspect of the story.
- This led us to introduce the persistence of a conversation which then
  suggested a separate ConversationRepository class rather than evolving
  the existing MessageRepository.
- Currently we are only displaying the subject of each conversation; the
  feature should be extended to drive the presence of the date and other
  attributes.
- Mirroring the design of the MessageRepository, the
  ConversationRepository delegates to a ConversationIndex to ensure
  that loading a collection of conversations is done efficiently given
  that this needs to happen within an HTTP request.
- The ConversationIndex implements a strategy for grouping messages into
  conversations which is agnostic of the underlying implementation of
  the persistence mechanism. We drove out the implementation of the
  ConversationIndex with some integration tests. Initially we got these
  tests passing by implementing a simplistic in-memory Array-based store
  which we then replaced with an ActiveRecord-based store.
- The strategy is, roughly: given a message, try to find a conversation
  which contains a message with the message_id referenced in our
  In-Reply-To header; if a conversation exists, add this message to that
  conversation, otherwise create a new conversation with just this
  message. Then, find any conversations which contain messages whose
  In-Reply-To headers point that this message; if any are found, merge
  those conversations with this one.
- We consciously kept the objects which the index and the repository
  return separate from the objects used to persist the data. This may
  make the ActiveRecord-based subclasses seem strange. We hope that this
  can be improved. We are really only using ActiveRecord as a convenient
  way to manipulate a SQL database, which might account for some of the
  convolution in its implementation.
- The ConversationRepository is passed to the MailImporter as a peer to
  the MessageRepository. This keeps the different concerns of messages
  and conversations separated, but we will likely want to wrap both
  repositories in a higher-level object; this will certainly allow the
  MailImporter tests to be simplified.

There are unfortunately a few orthogonal changes in this commit:

- MessageRepository#add_mail now returns the Message, although this
  isn't yet tested. We will add tests to explicitly specify this as
  required behaviour for a MessageRepository.
- The message_id method on a ::Mail instance sometimes returns an
  ActiveSupport String rather than a plain Ruby one, which is then
  stored in ElasticSearch as a 'wrapped_string', which subsequently causes
  issues if passed through to ActiveRecord for use in a query. We have
  added a fix to ensure that the objects ElasticSearchMessageIndex returns
  always respond to `#message_id` with a ruby String. Ideally we should
  also fix all of the existing data to be stored as normal Strings, but
  this may require re-importing all the data. Our hope is that this can be
  done as part of refactoring this fix out of the codebase, rather than
  increasing the size of this commit or delaying us putting this shit into
  master any further.

Well done! You've made it to the end of this message. We're sorry.