Add request body + query params to matcher entry

For APIs where parameters are part of the URIs, httpretty works fine:

```python
HTTPretty.register_uri(HTTPretty.GET,
    'https://example.com/widgets/1/status', body='ok')
HTTPretty.register_uri(HTTPretty.GET,
    'https://example.com/widgets/2/status', body='bad')
```

But when the parameters move to a POST body, the model of matching requests by method and URI alone breaks down - we need to be able to match on the body too:

```python
HTTPretty.register_uri(HTTPretty.POST,
    'https://example.com/widget-status',
    request_body='{"id": 1}', body='ok')
HTTPretty.register_uri(HTTPretty.POST,
    'https://example.com/widget-status',
    request_body='{"id": 2}', body='bad')
```

Another problem crops up when we have multiple query string parameters, and their values matter, but their order is arbitrary. This entry, for example,

```python
HTTPretty.register_uri(HTTPretty.GET,
    'https://example.com/widgets?status=ok&sort=name',
    match_querystring=True, body='[5,81]'))
```

matches
```
      https://example.com/widgets?status=ok&sort=name
```
but not
```
      https://example.com/widgets?sort=name&status=ok
```

We can fix this by adding another match criterion by which we specify the query string as a dict.

```python
HTTPretty.register_uri(HTTPretty.GET, 'https://example.com/widgets',
    query_params={'status': 'ok', 'sort': 'name'}, body='[5,81]'))
```

The logic of `URIMatcher.get_next_entry` is now generalized as: "Choose the first matching entry that hasn't been used yet. If all matching entries have been used, repeat the last one."