Projects gained a field for the MR source branch removal default.
MRs gained fields for whether there are blocking discussions or
conflicts, and for the squash commit used to integrate the MR.

This is to appease clippy's complexity checks. These are just tests, so
arbitrarily splitting them seems OK to me.

It's a test; we can just use `unwrap()` instead.

`PipelineBasic` gained fields for creation/update dates.

The order is stdlib before external crates before internal modules.

Projects gained fields for visibility of individual features.

They also gained fields for devops and build configuration.
Leave out bindings for these for now.

The live Gitlab project from which we fetch sample data has been
updated.  Update our sample and expected results accordingly.

In order to generate data for commit e0312dcf (types: Add resource label
events, 2019-07-16, v0.1200.1~1^2~1) a label was added to our sample
issue.  Fetch updated data for the issue and revise expected values.

Andrew Chin authored Jul 23, 2019 and Brad King committed Jul 24, 2019

This will expose the merge issue id or the issue id of the MR/issue on
which the resource label event was created.

Andrew Chin authored Jul 16, 2019 and Brad King committed Jul 24, 2019

Resource label events record are events that are recorded whenever a
label is added or removed to an issue/merge request.

This Gitlab API was added in 11.1, and so any labels added/removed
before this release will not appear in the data returned by this API.

Projects gained a field indicating whether they have an empty repo.
Issues gained a field indicating whether there is an empty task list.

Issues and MRs also gained a field for task completion, but we leave
that unimplemented for now.

The merge requests field for multiple assignees now includes an entry
for a single assignee.  Namespaces of projects gained fields for a URL
and an avatar.

Users gained a "highest_role" field when queried as an admin.

Projects and Merge Requests also gained some fields.  Add samples
to our test data but leave out the implementation for now.

This field will be set when you request a single merge request:

    /api/v4/projects/123/merge_requests/456

But it's missing if you request a list of merge requests:

    /api/v4/projects/123/merge_requests

Tested against a gitlab 11.9.7 server

Issues gained a field for the number of merge requests referencing them.
Merge requests gained a field for the current user's access.

Merge requests gained fields to report a merge error and whether a
rebase is in progress.

Users gained a field for their public email address, if any.