Prefix type parameters and lifetimes with double underscore

[dtolnay]

Addresses #312. We already do this almost everywhere.

[dtolnay]

The Travis failure is due to #313.

[oli-obk]

up to now the "style" of PRs was to rebase them instead of merging them. I think we should stay with that style.

[dtolnay]

Okay I rebased this PR and will rebase my other ones.

We can discuss this in a separate ticket if you are interested, but just to raise some points in favor of merge commits:

1. A large part of the point of PRs is code review. As PRs change, GitHub keeps track of what part each reviewer has seen. Every rebase screws that up and forces reviewers to start from the beginning.
2. Many times a PR has already been reviewed fully but is not ready to merge for a variety of reasons. If there are only merge commits since the time that it was reviewed, it is probably okay to merge. On the other hand if there is a single rebased commit, you have no idea. Better review the whole thing again to make sure nothing important has changed.
3. The "Files changed" view is no different whether there are merge commits or not. It shows you the diff compared to the base branch. So if that is your workflow, it is not hindered by merge commits.
4. If we care about preserving a relatively simple commit history, PRs that include merge commits can be rebased and squashed right at the end, after the review is finished.

[oli-obk]

I find your arguments very convincing, but I don't want to change the style without consulting @erickt, so lets open a new issue for now