Add new functionality to HelpScout::Threads (create, update, get)

[jjustinwhite]

This adds functionality to create and update a thread via the API. It also attempts to provide a "get" functionality, despite the HelpScout 2.0 API not supporting such an endpoint. It also update the README to reflect the API functionality lacking for a true GET and DELETE for Threads.

[prsimp]

@jjustinwhite thanks for the PR! I've left a few small comments but generally speaking this looks great. I'm looking in to fixing our Travis configuration so that PR builds will run correctly.

I think our VCR sanitization is strong enough that you should be able to record cassettes for these if you'd like, but if you'd prefer, I'm happy to record them myself and add them to the PR. Just let me know.

Thanks again for your work here 🤘

[prsimp]

@andremleblanc -- I went ahead and implemented my suggested changes. This could probably use another quick set of eyes for final approval.

Thanks again @jjustinwhite for the initial work!

[jjustinwhite]

Eek, I missed my notifications on this! Nice work @prsimp :) I'd never used VCR, and I tried figuring out how to record my own, but never figured it out. I'll have to look through what you did and figure out what I was doing wrong. Thanks for finishing that off!

[andremleblanc]

Couple of nitpicks, but overall looks good to me. Will test this a little later tonight.

[andremleblanc]

Feels like our getable shared example could be expanded to handle multiple args, but since I think this is the first instance of it, I'm cool with saving that for later.

[andremleblanc]

I think it would also be nice to add subclasses to thread (or some other abstraction) to document what valid thread types are.

For instance, to create a chat thread, you'd do something like:

HelpScout::Thread.create(1234, 'chats', { customer: { id: 5678 }, text: "Hey there" })

What do you think about something like:

HelpScout::Chat.create(conversation_id: 1234, customer_id: 5678, text: "Hey there")

That being said, I could see adding this abstraction later and not having to break the interface, so I'm good with this for now.

@prsimp

[andremleblanc]

Tested this locally and works as expected 👍

[jjustinwhite]

Thanks for the review @andremleblanc & @prsimp! I agree, subclasses like HelpScout::Chat would look a lot nicer than passing the thread type into HelpScout::Thread. I'd be happy to take a stab at that in another PR too.

[prsimp]

I think it would also be nice to add subclasses to thread (or some other abstraction) to document what valid thread types are.

Absolutely. I think the same can be said for Thread and Conversation updates. Encapsulating (or at least validating) the somewhat arcane syntax into something like Conversation#update_subject would be really nice.

I'd be happy to take a stab at that in another PR too.

@jjustinwhite thanks! Feel free to take a stab at it if you find some time -- I'll open an Issue for some ongoing discussion about the topic.