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.

Implemented simple gist functionality ref #530.

- creation of public/private gists with given lifetime
- rhodecode-gist CLI for quick gist creation

locking API returns objects instead of string messages.

- it's now possible to easily parse the output of lock functions

fixed broken API tests after excluding default user
from users listing

invalidation: don't create CacheInvalidation records on startup

Creating the records early gave an advantage before lightweight was introduced.
With lightweight it is no longer necessary.

The records will be created on demand anyway and there is no reason to create and
maintain them before they are used.

api: don't report invalidated cache_keys after invalidating a repo

The keys are an implementation detail and is never relevant outside RhodeCode
internals and should not be leaked.

- Manage User’s Groups: create, delete, rename, add/remove users inside.
by user group admin.
In this case, a user's group can be owned by several people thru an owner user's group.

Some refactoring of naming, permission handling logic.
- remove some code duplicity as well as inconsistent naming

more usage of fixture tools
in tests

further cleanup of UsersGroup

Renaming some names ... but trying not to change API or database scheme.

API methods create_repo, fork_repo, delete_repo, get_repo, get_repos
can be executed by non-admin users ref #539

Implemented #379 defaults settings page for creation of repositories
- locking
- statistics, downloads
- repository type

Added functional test create repo with a group
- unified calling Session in tests

Refactored API
- added ~100% line coverage tests for api
- test against hg and git