Support structured request bodies #242

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Right now, request bodies are only defined as strings (technically you can pass any primitive value, which will parse as a template). There is a use case for defining structured bodies, where the exact structure and semantics would be determined by the Content-Type header.

See #235 for more context.

Describe the solution you'd like
A clear and concise description of what you want to happen

By default, the body is deserialized as just a template. For structured data, you have to provide a tag to tell Slumber the structure type. Some examples:

chains:
  cod_image: !file
    path: ./cod_photo.jpg
requests:
  create_fish: !request
    method: POST
    url: "{{host}}/fishes"
    headers:
      Content-Type: application/json
    body: !json
      id: "cod"
      name: "Rod"
  upload_fish_image: !request
    method: POST
    url: "{{host}}/fishes/image"
    headers:
      Content-Type: multipart/form-data
    body: !form
      fish_id: "cod"
      fish_image: "{{chains.cod_image}}"

Advantages:

• Unambiguous and easy to deserialize
• Checking if the body type matches the content type is easy. For each content type we can define a simple list of valid body types.

Disadvantages:

• You have to define your content type in two places: the Content-Type header and the body tag

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered

We could support any type for the body (i.e. arbitrary primitives, maps, and arrays), but that introduces ambiguity. I considered this very early on in the project and decided against it for that reason. For example:

requests:
  create_fish: !request
    method: POST
    url: "{{host}}/fishes"
    headers:
      Content-Type: application/json
    body: '{id: "cod", name: "Rod"}'

What would the body be here? Should we submit {id: "cod", name: "Rod"} or "{id: \"cod\", name: \"Rod\"}"? The user probably meant the former but if we automatically convert the given value to JSON, then it should be stringified to the latter. In addition to being confusing and ambiguous, this would also be a massive breaking change.

Additional context
Add any other context or screenshots about the feature request here

To begin with, this should only support JSON. Forms should be added in separate PRs.