Artifacts metadata field will be used to store a filename of gzipped
file containing metadata definition for given artifacts archive.

This is needed because of backward compatibility. Previously artifacts
archive had `.tar.gz` format, but artifacts browser requires ZIP format
now.

`artifacts?` method checks if artifacts archive is available.

This support is not completed though, as parent directory that is first
in collection returned by `directories!` is not iterable yet.

This implementation makes it possible to browse artifacts, it
depends on artifacts metadata.

`StringPath` class is something similar to Ruby's `Pathname` class,
but does not involve any IO operations. `StringPath` objects require
passing string representation of path, and array of paths that
represents universe to constructor to be intantiated.

This reverts nesting artifacts controller in builds module.

This will contain serialized array of files inside artifacts tarball.

Improve the consistency of commit titles, branch names, tag names, issue/MR titles, on their respective project pages

See #3956.

Following is before/after for each page:

## Group title

### Before
![group-title-before](/uploads/d6c013c69f526d553555ff974c29b349/group-title-before.png)

### After
![group-title-after](/uploads/56e0bd176d12943297b5b95d20beb437/group-title-after.png)

---

## Commit title

### Before
![commit-title-before](/uploads/a9bda5212eea843ab4c92acbcf411cdd/commit-title-before.png)

### After
![commit-title-after](/uploads/e3a532460a1e7b0b2a8eb8a6af12abea/commit-title-after.png)

---

## Branch name

### Before
![branch-name-before](/uploads/9d77e39f07cd7b757d02a39f5bc57570/branch-name-before.png)

### After
![branch-name-after](/uploads/6831e9560d196d8a4da209166f224a0f/branch-name-after.png)

---

## Tags name in list

### Before
![tags-name-in-list-before](/uploads/cf0141713af751132fd29220621ea9ab/tags-name-in-list-before.png)

### After
![tags-name-in-list-after](/uploads/902c5b029dc832216ac536d2ad372b83/tags-name-in-list-after.png)

---

## Tag name

### Before
![tags-name-before](/uploads/495acb6b4bab8464a0ffeb8f703435b6/tags-name-before.png)

### After
![tags-name-after](/uploads/f86868dbad57b8226611bcb03e5a9524/tags-name-after.png)

---

## Issue title in list

### Before
![issue-title-in-list-before](/uploads/5f01450aceefdcc2f51984832a4ce6b5/issue-title-in-list-before.png)

### After
![issue-title-in-list-after](/uploads/3144fb231874d23b6b46e108da24b128/issue-title-in-list-after.png)

---

## MR title in list

### Before
![mr-title-in-list-before](/uploads/bd0239104ebf4a5090c724c3851df57c/mr-title-in-list-before.png)

### After
![mr-title-in-list-after](/uploads/16be5460dffc33ff173a6b8ff3250206/mr-title-in-list-after.png)

See merge request !2422

LDAP Sync blocked user edgecases

Allow GitLab admins to block otherwise valid GitLab LDAP users
(https://gitlab.com/gitlab-org/gitlab-ce/issues/3462)

Based on the discussion on the original issue, we are going to differentiate "normal" block operations to the ldap automatic ones in order to make some decisions when its one or the other.

Expected behavior:

- [x] "ldap_blocked" users respond to both `blocked?` and `ldap_blocked?`
- [x] "ldap_blocked" users can't be unblocked by the Admin UI
- [x] "ldap_blocked" users can't be unblocked by the API
- [x] Block operations that are originated from LDAP synchronization will flag user as "ldap_blocked"
- [x] Only "ldap_blocked" users will be automatically unblocked by LDAP synchronization
- [x] When LDAP identity is removed, we should convert `ldap_blocked` into `blocked`
 
Mockup for the Admin UI with both "ldap_blocked" and normal "blocked" users:
![image](/uploads/4f56fc17b73cb2c9e2a154a22e7ad291/image.png)

There will be another MR for the EE version.

See merge request !2242