They will need to be called with the classpath and main class now,
instead of simply using the Jar.

The (moxie and other) Launcher do not work with Java 9 and later anymore.
It used to dynamically extend the classpath, misusing an internal
interface of the `URLClassLoader`. This is no longer possible since Java 9,
which closed that path and does not offer any way to dynamically extend
the classpath during runtime.

So the choice is between providing one large Jar with everything in it,
providing a Jar that has the Jars in `ext` listed explicitly in its
manifest, and specifying the classpath on the command line where
the `ext` directory can be added and all contained jar files will
be put on the classpath.

The motivation for the Launcher class was to be able to simply drop
new jar files into a directory and they will be picked up at the
application start, without having to specify a classpath. We opt
for solution three here. This way jar files can still be dropped
into the ext directory, albeit the directory needs to be added to
the classpath on the command line. Unfortunately using a wildcard
is not possible in the manifest file. We change the calls in the
script files accordingly. This seems like a good compromise,
since no one will run the application manually typing the whole
commandline anyway.

This also does away with the splash screen, by the way. Again,
doesn't seem like a big loss, as I don't think it was ever shown
for the Authority.

Personally, I am not convinced that it is the best way, because
I don't really think that the use case of dropping whatever jar
files into the `ext` directory is a valid one that happened a lot.

This does not yet fix the client programs, which still use a
Launcher. Maybe for them a all-in-one Jar is a better solution.

Fixes #1262
Fixes #1294

With three versions about to be supported right now
it is getting more important to know which Java version is
used when building and testing Gitblit, and which Java
version is used to run Gitblit.

So have the Moxie build report the javac version, and the
JVM version that Moxie is running on. These might be
different.
The `GitBlitServer` will print the Java version and vendor,
so that it gets visible if a user would paste a log output
for analysis.

This hello-world.git repo is created using the native Git for Windows
software.

Various test classes in the GitBlitSuite test suite require the presence
of the hello-world.git repo in github.com/git/ which has been missing,
hence causing many test failures in the suite. This recreation of the
hello-world.git repo aims to conform to the many test cases'
requirements in the suite, and to be checked in as part of the gitblit
repo, thus eliminates the requirement of a remote hello-world.git repo
during the test run. The repo is now stored is a zip ball in the new
src/test/data folder.

The hello-world repo's various commit IDs were hard-coded in various
test classes. These commit IDs, which must now have new values in the
recreated repo, are now extracted out to the
src/test/data/hello-world.properties file. The gitblit's build.xml is
modified to generate the HelloworldKeys.java file containing the
hello-world.properties file's key strings, in similar fashion as the
existing generation of the com.gitblit.Keys.java file. And these key
strings in HelloworldKeys.java are now used in the various test classes,
thus eliminating the hard-coding of the hello-world repo's commit IDs in
the test code.

During the test run by GitBlitSuite test suite, some repos from GitHub
were cloned and became part of the test data. These repos are now zipped
to be part of gitblit repo itself, thus eliminating the network fetch at
the start of test run which can be slow, especially with the JGit repo
cloning which is huge and time consuming. The cloned JGit repo is now
zipped and checked in to gitblit, along with the other 4 repos
(hello-world, ambition, gitective and ticgit). They will be unzipped
during the test suite run and be available in the local file system,
thus avoiding the need for some network fetch.

Special note on the zipped JGit repo: this repo is big (and growing all
the time on GitHub), and takes up about 32MB of disk space after cloning
from GitHub. I've made it smaller by resetting HEAD back to a commit of
5 years ago (with git reset --hard <commitId> command), to put it back
to roughly where/when the tests were written for it (which is not quite,
because there are tons of commit history since which can't be removed.)
The local JGit repo is then garbage-collected (with git gc --prune
--aggressive) to reduce its size to about 19MB.

Zipped it is still 17MB. This is a lot of MBs for a few tests.
So the JGit repo is not included in this commit.

Fixes #1275

That will fix build of javadoc in Windows zh-cn (and maybe some other locale).
Unknown why javac works well.

+ New docEdit page with links from docPage and docList
+ Bespoke menu system with full screen edit mode
+ npm required for building client side scripts
+ Ant script added for BuildUI which performs npm commands
+ Update font-awesome to 4.5.0
+ Factor out to JGitUtils common code in BranchTicketService for EditFilePage
	+ getTreeEntries
	+ commitIndex
+ Merge capability for document editing

+ Filestore listing filtered by user view permissions
+ Configuration help for filestore relocated to website files
+ Added migration example

A basic issue tracker styled as a hybrid of GitHub and BitBucket issues.
You may attach commits to an existing ticket or you can push a single
commit to create a *proposal* ticket.

Tickets keep track of patchsets (one or more commits) and allow patchset
rewriting (rebase, amend, squash) by detecing the non-fast-forward
update and assigning a new patchset number to the new commits.

Ticket tracker
--------------

The ticket tracker stores tickets as an append-only journal of changes.
The journals are deserialized and a ticket is built by applying the
journal entries.  Tickets are indexed using Apache Lucene and all
queries and searches are executed against this Lucene index.

There is one trade-off to this persistence design: user attributions are
non-relational.

What does that mean?  Each journal entry stores the username of the
author.  If the username changes in the user service, the journal entry
will not reflect that change because the values are hard-coded.

Here are a few reasons/justifications for this design choice:

1. commit identifications (author, committer, tagger) are non-relational
2. maintains the KISS principle
3. your favorite text editor can still be your administration tool

Persistence Choices
-------------------

**FileTicketService**: stores journals on the filesystem
**BranchTicketService**: stores journals on an orphan branch
**RedisTicketService**: stores journals in a Redis key-value datastore

It should be relatively straight-forward to develop other backends
(MongoDB, etc) as long as the journal design is preserved.

Pushing Commits
---------------

Each push to a ticket is identified as a patchset revision.  A patchset
revision may add commits to the patchset (fast-forward) OR a patchset
revision may rewrite history (rebase, squash, rebase+squash, or amend).
Patchset authors should not be afraid to polish, revise, and rewrite
their code before merging into the proposed branch.

Gitblit will create one ref for each patchset.  These refs are updated
for fast-forward pushes or created for rewrites.  They are formatted as
`refs/tickets/{shard}/{id}/{patchset}`.  The *shard*  is the last two
digits of the id.  If the id < 10, prefix a 0.  The *shard* is always
two digits long.  The shard's purpose is to ensure Gitblit doesn't
exceed any filesystem directory limits for file creation.

**Creating a Proposal Ticket**

You may create a new change proposal ticket just by pushing a **single
commit** to `refs/for/{branch}` where branch is the proposed integration
branch OR `refs/for/new` or `refs/for/default` which both will use the
default repository branch.

    git push origin HEAD:refs/for/new

**Updating a Patchset**

The safe way to update an existing patchset is to push to the patchset
ref.

    git push origin HEAD:refs/heads/ticket/{id}

This ensures you do not accidentally create a new patchset in the event
that the patchset was updated after you last pulled.

The not-so-safe way to update an existing patchset is to push using the
magic ref.

    git push origin HEAD:refs/for/{id}

This push ref will update an exisitng patchset OR create a new patchset
if the update is non-fast-forward.

**Rebasing, Squashing, Amending**

Gitblit makes rebasing, squashing, and amending patchsets easy.

Normally, pushing a non-fast-forward update would require rewind (RW+)
repository permissions.  Gitblit provides a magic ref which will allow
ticket participants to rewrite a ticket patchset as long as the ticket
is open.

    git push origin HEAD:refs/for/{id}

Pushing changes to this ref allows the patchset authors to rebase,
squash, or amend the patchset commits without requiring client-side use
of the *--force* flag on push AND without requiring RW+ permission to
the repository.  Since each patchset is tracked with a ref it is easy to
recover from accidental non-fast-forward updates.

Features
--------

- Ticket tracker with status changes and responsible assignments
- Patchset revision scoring mechanism
- Update/Rewrite patchset handling
- Close-on-push detection
- Server-side Merge button for simple merges
- Comments with Markdown syntax support
- Rich mail notifications
- Voting
- Mentions
- Watch lists
- Querying
- Searches
- Partial miletones support
- Multiple backend options

Change-Id: I5ff18b2768095fb14e7fbece2e756115829abbde

Change-Id: I9bb2cc0cbfac9841b13bed15a474fefb24355cd4

Change-Id: I8e0479b632af3b5ca809aacf955e4be96822ac2c

Change-Id: I06dbc0fdad93c042d783c97378429856bd9111bf

Change-Id: Ia4c9536282af6df3d9d462946dec1d8112459242

The mirror executor will fetch ref updates for repository mirrors.  This
feature is disabled by default and can be enabled by setting
git.enableMirroring=true.  The period between update checks is
configurable, but it is global.  An individual rpeository may not set
it's own update schedule.

Requirements:
1. you must manually clone the repository using native git
   git clone --mirror git://somewhere.com/myrepo.git
2. the "origin" remote must be the mirror source
3. the "origin" repository must be accessible without authentication OR
   the credentials must be embedded in the origin url (not recommended)

Notes:
1. "origin" SSH urls are untested and not likely to work
2. mirrors cloned while Gitblit is running are likely to require
   clearing the gitblit cache (link on the repositories page of an
   administrator account)
3. Gitblit will automatically repair any invalid fetch refspecs with a
   "//" sequence.

Change-Id: I4bbe3fb2df106366ae4c2313596d0fab0dfcac46

Change-Id: I94d4f6146c79541bf8a36e4c3dca1842e46cddd5