Gitorious Apocalypse: recovery existing clone

These instructions are simple and I've tested them.

Gitorious Apocalypse: remove all gitorious URLs

The Gitorious URLs will disappear in the next few hours. The canonical
hosting location of this project is now on copyleft.org. Specific
gitorious URLs are generally replaced with k.copyleft.org, which is
copyleft.org's self-hosted Kallithea instance.

Contributing text from third-party works.

Integration of text from third-party works is complicated, since the
text must be incorporated to flow properly with the rest of the Guide.
Also, historical archiving commits are particularly useful in such
situations. This tutorial explains how to contribute such additions for
this project.

Citations of third-party works in appendix only.

As alluded to in 2ea19b71d4a917babb29024f06acabfe73309f40 's commit
message on 2014-12-17 19:52:15 -0500, keeping any information on a
part-by-part basis is difficult and error-prone, since there exists no
reliable way to auto-generate such information accurately.

Therefore, citations to third-party works, in addition to remaining
fully documented in the commit log as they always have been, are now
placed in specifically one location in the body of the text itself: a
single appendix specifically designed for that purpose.

In this manner, contributors have no house-keeping work regarding
citations. Contributors need only list third party works and links in
one place: third-party-citations.tex.

Documentation in CONTRIBUTING.md for making contributions of third-party
works is left as a TODO.

Document work-around for 'next' branch rebases.

Upstream in the copyleft.org tutorial repository, the next branch is
sometimes rebased against the master branch. (For example, this occurs
when there have been quick fixes done on 'master' while new drafting
occurs on 'next'.)

This procedure, while convoluted, is the best way I've found to
compensate for this problem. Hosting sites like Gitorious really aren't
designed for rebased branches.

No instructions for 'master';just note possibility

Ultimately, users will probably pick either 'master' or 'next' to submit
changes anyway, so just leave the instructions to refer to 'next' and
note that they could replace 'next' with 'master'.

Detailed merge request instructions for Gitorious.

Most Gitorious users know this procedure, but it seems useful to
document it in great detail here, since copyleft.org seeks contributions
from those who might be knew to Git, and those who are more familiar
with procedures of other collaboration sites.

Note merge request should usually target next.

Some targets to master are acceptable, though.