Give project selection dropdowns responsive width, long names wrap.

## What does this MR do?

Makes two dropdown menus (branch name selector & project selector) wider on larger screens, and allows their contents to wrap.

## Are there points in the code the reviewer needs to double check?

Sanity check. 

## Why was this MR needed?

Considered a regression, as users who relied on long branch names could no longer see them fully. 

## Screenshots (if relevant)

Before: 
![Screen_Shot_2016-08-30_at_2.50.43_PM](/uploads/e0252cb02c5f34f3c777d2d67028042f/Screen_Shot_2016-08-30_at_2.50.43_PM.png)

After:
![Screen_Shot_2016-08-30_at_2.49.35_PM](/uploads/b504e0f3e139c85699bc5aafb58199f3/Screen_Shot_2016-08-30_at_2.49.35_PM.png)

After (updated after fixes, including project selector): 

![Screen_Shot_2016-09-02_at_1.46.53_PM](/uploads/b480fc8193f713ce43518cb83886fd52/Screen_Shot_2016-09-02_at_1.46.53_PM.png)

![Screen_Shot_2016-09-02_at_1.50.26_PM](/uploads/f0d31702668e83e6c0c24782cc43fdbd/Screen_Shot_2016-09-02_at_1.50.26_PM.png)
## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] API support added
- Tests
  - [x] Added for this feature/bug
  - [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?

Closes #15633

See merge request !6105

Smartly calculate real running time and pending time

## What does this MR do?

Try to smartly calculate the running time and pending time for pipelines, instead of just use wall clock time from start to end. The algorithm is based on:

> Suppose we have A, B, and C jobs:

> * A: from 1 to 3
> * B: from 2 to 4
> * C: from 6 to 7

> The processing time should be accumulated from 1 to 4, and 6 to 7, totally 4, excluding retires, and calculate on `%w[success failed running canceled]` jobs (if a job is not finished yet, assume it's `Time.now`)

## Are there points in the code the reviewer needs to double check?

I would actually like to test `Gitlab::Ci::PipelineDuration#process_segments`, but it's a private method right now and it's not very convenient to test it. Is there a way to test it without changing the original code too much? Note that I would like to avoid saving merged segments because it's not used and should be garbage collected.

## Screenshots:

![Screen_Shot_2016-09-05_at_6.45.32_PM](/uploads/a82bfaf316661091e383b743a2f11334/Screen_Shot_2016-09-05_at_6.45.32_PM.png)

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- Tests
  - [x] Added for this feature/bug

## What are the relevant issue numbers?

Closes #18260, #19804

See merge request !6084

Implement Slack integration for pipeline hooks

## What does this MR do?

Add pipeline events to Slack integration

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- Tests
  - [x] Added for this feature/bug

See merge request !5525

Add bulk update support for merge requests list

## What does this MR do?

Adds new feature: ability to update multiple merge requests at once from index page (same like we have for issues already)

## Are there points in the code the reviewer needs to double check?

I don't think so

## Why was this MR needed?

* consistency with issues
* save user time when you want set same label/milestone to 20 merge requests 

## Screenshots (if relevant)

![Screenshot_2016-09-08_11.48.49](/uploads/fe50b2472330e211eb8d6d6dafb15667/Screenshot_2016-09-08_11.48.49.png)![Screenshot_2016-09-08_11.48.46](/uploads/4833c3705120ec028f7a62a4e128998d/Screenshot_2016-09-08_11.48.46.png)

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] ~~[Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- [x] ~~API support added~~
- Tests
  - [x] Added for this feature/bug
  - [x] All builds are passing
- [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/20087

See merge request !6226

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6084#note_15091858

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6084#note_15083507