data/eval/_multistage_traineval.sh: Use phase-specific barriers

I just encountered a case where phase 2 went through too quickly in training and the testing got stuck on a barrier forever.
DBpedia: Migrate from Virtuoso to Jena Fuseki as backend database

This is a backwards incompatible change, sorry - if you are using an
older version of YodaQA, you need to update the endpoint.  We still use
DBpedia 3.9 datasets, though.

Virtuoso really sucks.  Its queries are maybe a little faster, but it
can't keep its database in a clean state.  A mere restart of the daemon
seems to be enough to get stuck indefinitely on some queries, and
a clean import of data will result in corrupted database warnings and
the same thing.
data/dbpedia/README: Re-add note about CachedJenaLookup change
AnswerScoreLogistic: Update the model
Merge branch 'master' of github.com:brmson/yodaqa
data/eval/README: Add a recipe for manual tsvgs run
AnswerGSHook: Revamp the 'train from the only first correct answer' idea

The problem is that our model training is highly non-stationary now (new
trained model depends on the previous model - this is not desirable) and
it is a real problem both in terms of performance drift and
degeneration.

Therefore, do not do this in the initial phase, making phase 1 the first
natural 'pruning' phrase from the angle of both reduce-to-100 and this,
and in the followup phases use the score from the previous phase for
correct answer selection. This keeps the nifty feature but makes the
model stationary again.
AnswerScoreLogistic: Update the model
Merge branch 'master' into f/qfhowverb