First step in two-part process to rename directories to kallithea.
This first step is to change all references in the files where they refer
to the old directory name.

Imported some of the GPLv3'd changes from RhodeCode v2.2.5.

This imports changes between changesets 21af6c4eab3d and 6177597791c2 in
RhodeCode's original repository, including only changes to Python files and HTML.

RhodeCode clearly licensed its changes to these files under GPLv3
in their /LICENSE file, which states the following:
The Python code and integrated HTML are licensed under the GPLv3 license.

(See:
https://code.rhodecode.com/rhodecode/files/v2.2.5/LICENSE
or
http://web.archive.org/web/20140512193334/https://code.rhodecode.com/rhodecode/files/f3b123159901f15426d18e3dc395e8369f70ebe0/LICENSE
for an online copy of that LICENSE file)

Conservancy reviewed these changes and confirmed that they can be licensed as
a whole to the Kallithea project under GPLv3-only.

While some of the contents committed herein are clearly licensed
GPLv3-or-later, on the whole we must assume the are GPLv3-only, since the
statement above from RhodeCode indicates that they intend GPLv3-only as their
license, per GPLv3§14 and other relevant sections of GPLv3.

emailing: log failing emailing as an error

TODO: The failure should be reported back to the user (or the admins). The
system should not silently not send any emails to the targeted recipients.

Even better: it should inform the user whenever emails was (scheduled to be)
sent - and to whom.

compare: move get_changesets to compare controller where it is used - 2nd half that was lost in 6c79bfcd3b54

That is a better location than the pull request model. It should probably be
split up and moved to the backend specific Repository classes.

pullrequests: optimize locating changeset to compare

We only need the max revision - that is much faster when a branch is specified.

pullrequests: use hashes instead of changecontexts

The changecontexts was converted to hex strings when stringified, but better be
explicit.

pullrequests: handle the case where no matching revisions are found for either end

Use -1 as default revision - that is the null revision.

pullrequests: simplify handling of null revisions

Undo unnecessary and incorrect code introduced in bd5420ea396b.

compare/pullrequest: introduce merge parameter

This is more correct and flexible than the old way of looking on same/different
repo.

notifications changes
- closing pull requests will give notification about it
- more detailed notifications about commenting on changesets and pull requests

fixed pull-requests with cherry picking changesets
- fixed tests for them

compare: show aggregated diff of what will be merged to other repo, using merge ancestor

pull_request.get_compare_data will also now return the ancestor that would be
used for actual merging. Showing a diff from that ancestor instead of the first
'new' changeset will give a more realistic diff that doesn't include merges.

compare: swap org and other when they refer to different repos, ie are pull request style

Pull requests will have a different from/to description - but in a consistent
and slightly better way that can be improved later.

A pull request diff is empathic: "How will this look for the peer I'm proposing to" style.

pull request: use unionrepo instead of outgoing

This makes it possible to look the 'moving target' symbols up in the right repo.

Using a revset with the right revisions also removes the need for pruning
changesets that are outside the requested range.

It will also not be confused by changesets that for some reason has been pulled
to the repo but haven't been merged yet. They are going to be 'merged' by the
'pull' request and should thus be a part of what is reviewed.

pull requeset: move stuff around, preparing for next change

- and make sure we don't pass unicode to Mercurial

set the status of changesets initially on pull request, and make sure we care of version collisions.
Fixes issues #690 and #587

Basic implementation of cherry picking changesets
for pull request, ref #575

Multiple changes for compare system
- count number of changed lines and files
- add combined compare button into the old per changeset compare
- fixed some logic for remote & bundle compare system
- added few tests for git compare

Enabled compare engine for tags
Implemented compare engine for git repositories

fixes #550 mercurial repositories comparision failed when origin repo had
additional not-common changesets + added regresion test for this

Bumped mercurial version to 2.3
- fixed issues with compare of two remote repos at particular revisions
- added tests for cases when mercurial update broke code and tests didn't catch this
- removed obsolete EmptyChangeset from the rhodecode code

Merged pull request #56
- fixed issue with resolution of ref_types for mercurial
- now properly handles ref type
- added option to compare by specific revisions also

Switch to waitress wsgi server by default in rhodecode.
- waitress is fast, handles chunked encoding correctly (needed for git)
- waitress works on linux and windows
- it's now default because it can handle git properly out of the box.

Added dynamic data loading for other repo we open pull request against
- fixed notification emails, now with link to comment or status change in given pull request

- pull request generates overview based on it's params
- added page to show all pull-requests for a repository
- db schema changes to support comments and inline comments for pull-requests

Added basic models for saving open pull requests
- added pull-request models
- added pull-requests notifications into inbox