Added documentation for passing the token as header

The documentation was unclear about how to pass the api private token as
header. Updated the doc to include the nessesary information bits and
added an example using the curl command line client.
describe the project access level

the documentation mentions access_level as required parameter, but fails to list
accepted values.
Update docs to reflect that project names are allowed as ID

The API accepts project names in all places where project IDs are expected. Updated the docs to
reflect that.
rescue all errors and return the proper format

This rescues all errors and returns a proper JSON response. Fixes #2833.
default gitlab.relative_url_root to ENV['RAILS_RELATIVE_URL_ROOT']
remove hardcoded app_dir from unicorn.rb.example
log fatal errors that we catch

In case we rescue from a fatal error, we want the error and the backtrace to
the error logged, so we can debug later on. This change injects the configured
logger from the rails app to the grape API and logs error as well as backtrace
in a rails-like fashion.
Don't crash when removing a user that's not project member

The attempt to revoke project access for a user that was not member of the
project results in a 500 Internal Server error where it actually should
result in a 200 OK since after the operation, the user is not member of
the project. This turns the operation into an idempotent call that can
be repeated with no ill effects.

Updated the spec and changed the code accordingly. However, the result differs
slightly, as we can't return the users project access level if the user was not
member. I'm not aware if anybody relies on the result of this call.

Fixes #2832
update api documentation for delete team member

correctly describes the new behavior
Show only ≤16 lines of code in a discussion (fix issue #2860).
Replacing the manual parsing of the /etc/group file with the equivalent call from the Etc class in the Ruby standard library. This has the benefit of supporting additional platforms (e.g. OS X).
Creating or updating a MR returns more informative status codes.

Using the API library to create or update a merge request at the moment a 404 error is returned.
This is fine when the merge request in question does not exist, but does not provide good
information that for example a required attribute is missing.
A status code of 400 (Bad request) is returned when creating or updating a merge request
when either `source_branch` or `target_branch` is missing. A status code of 409 is returned
when `source_branch` and `target_branch` are the same. Tests are added for these cases.
Extracted helper method to avoid code duplication
Creating MR comment without a note returns status code 400 (Bad request)

Creating a comment to an existing merge request via API without providing a note
returns a status code 400 now, suggesting a bad request. The reason for this
is the resource itself (MR) exists but the required property is not set.
Test added to check creation of note to a non-existent MR via API
Status code 400 returned if title not given in a milestone (via API)

If a milestone is created via API but no title given then status code 400 (Bad request)
is returned instead of 404. A small helper method handles the errors collection of a
milestone.
Tests added to check status codes when handling milestone via API

A few more tests added to check status code when creating or updating milestones.
Status code 400 is returned if body is missing on note creation.

If a note is created with a POST request via API (`/projects/:id/notes`) status
code 400 is returned instead of 404. The resource itself exists but the request
is incomplete. Specs added to check different status codes when accessing, creating
and updating notes.
A few fixes in documentation to notes, updates infos on status codes

A few fixes in the notes URI pattern (`notes` instead of `:notes`), also updated
the information to status codes. If `body` attribute is missing from a POST request
a status code 400 (Bad request) is returned. This reflects the code changes from
the previous commit.
Test to check a user must be part of the team to see project.

A user must be part of the team to see a protected project. A test is given
to check that a 404 error is returned if the user can not see the project.