Issue title: Replace httpie for curl
 Issue body: httpie is not consistent across all Linux distributions. Some customers might not be willing to install it either.
 Comments: 
 Comment 0: Really?
Who would not install httpie for their training environment? And why is "curl" better?
 Comment 1: I love httpie, and would definitely encourage anybody to install it - both in training and production environments.

But certainly if the customer has a strict policy on their testing machines, and for example deploy standard server VMs to do the training on, it can certainly be a problem. But if it's packaged in EPEL (which I think it is? Thoug not sure?), I'm not sure if it's a bigger problem than installing Varnish itself?
 Comment 2: The training requires local root.
If they can't install httpie in their training environment they figure out how to use curl on their own. 

There is absolutely no need to suboptimize the book just because someone has a lame security policy.
 Comment 3: I think a reasonable compromise would perhaps be to use httpie in the examples and such, but then include a small section of "here's how you do the most common things in curl as well" - for those that are stuck with it. But using httpie "inline".

 Comment 4: We leave httpie in.
If somebody cares enough about this to contribute a little appendix on curl usage I'm sure pull requests would be pulled with a smile and a nice pat on the back. :-)
 Comment 5: I'll wait until Dridi is back from vacation to comment on this issue. It is my understanding that he faced many problems with httpie while teaching at a customer's site.
 Comment 6: In the Varnish 3 series of the Varnish Book, I used to get negative feedback on the `GET` command, because unlike `curl` they couldn't figure what the flags would mean.

For my first Varnish 4 training, the customer had decided to host the VMs used for training, and they use RHEL 6. Httpie couldn't be installed via EPEL and they eventually tried with `pip` but in the end it didn't work.

Fallback to curl, but looking at `http` commands they did not understand what was going on, especially the developers (it was a 3 days training including both courses). And there's a terrible UI decision in httpie that leads to confusion.

`http -p hH --proxy=http:http://localhost sport.example.com/index.html`

The `--proxy` option is confusion because:
- of the http:http: double scheme
- the very name "proxy"
- the impedance mismatch with HTTP

They first thought that they had to specify this to bypass their corporate proxy. Then they thought that doubling `http:` was a typo. And then they didn't understand the relationship between this and a `Host:` header.

If we keep httpie, we should for instance get rid of all `--proxy` options and simply follow the principle of lest astonishment.

`http -p hH localhost/index.html Host:sport.example.com`

Same result, a lot closer to reality. That is important during training to not confuse trainees, they already have a hard time with VCL.

Now why `curl`?

It doesn't pretty print the output, it doesn't have colors. But really when a trainee is on a windows laptop using putty, they have bad UX anyway. And it's not that hard to read one key:value per line.

It is more verbose:

``` bash
http -p hH localhost/index.html Host:sport.example.com
# vs
curl --verbose --header Host:sport.example.com localhost/index.html
# vs
curl -v -H Host:sport.example.com localhost/index.html
```

And you don't get to pick what's printed, that one thing httpie does way better. But during the training, you only access to small files so it doesn't really hurt. Only the chapters _HTTP_ and _Content Composition_ contain large (for a terminal) files, but you look at them through a browser, and we use the developer tools to look at the HTTP bits.

And the main reason for using `curl` is not that I'm used to it and sysadmins are usually too as described above. The main reason is stability and consistency. Curl is mature, and available on all the platforms we support. Differences in feature (if any) between one shipped in RHEL 5 or 7 doesn't change anything for the training and is thus reliable.

We want to waste the least possible time and neurons during a training, because Varnish is disruptive, and therefore we need the most stable and comfortable environment possible.

My $0.02

 Comment 7: Those are valid objections. Probably worth a tad bit more than $.02, maybe as much as $.5. :-)

I'll see if I can find the time to rewrite some of the httpie statements to be more in line with best practices. The use of --proxy is probably a bit distracting and should be placed.

I suggest we move along with the current toolset and at a later point, when we're happy with the rest of the content we can add curl examples alongside the httpie ones. As you say, curl is omnipresent and a well known tool. However, my personal option is that httpie is a lot more powerful (the native JSON support is very nice).
You might scoff at the color support in httpie, but for me it makes a bit of a difference. I've abandoned curl quite a bit of time ago. 

 Comment 8: @perbu I use httpie when I want to look at the payload itself, because color support becomes very useful there!

I still use curl for both interactive commands and scripting, so unless I'm interested in looking at the response body, I stick to it.

During the training, we rarely look at the body, and AFAIK there's no json involved. When we do care about the body, we use a proper browser.

 Comment 9: Closed because this issue is a bit subjective and we better use our resources in more meaningful improvements for the book.

{'source': 'GithubIssues', 'repo_name_with_owner': 'varnish/Varnish-Book', 'issue_id': 71623125, 'repo_stars': 390.0}