[FIXED JENKINS-17177] wrong build result in post build steps after failed pre build step in maven project

based on the conversation with Weltraumschaf (the DARCS plugin maintainer)

Generally the environment is responsible for imposing a general timeout on tests.
And this timeout makes debugging more difficult.

Made the in-flight build survive the reload from the disk.

And since it's now a symlink that points to another symlink that then
points to the real stuff, we need recursive onion peeling.

Report 100 recent builds in the JSON API, including in-progress builds.

Not reporting all the builds since this would nullify the lazy loading
effect. Will introduce a pagenation API that supports retrieval.

[JENKINS-15533] testing if the lazy loading can gracefully tolerate a RuntimeException during unmarshalling.

At least in the current version this working as expected

The actual fix was in the pull request #675.

- ID_FORMATTER is time zone sensitive, so comparing against # of
  milliseconds since the epoch won't be portable.

- resolveSymlink can return a relative path.

Based on comments from Jesse, revising the fix.

I'm now putting permlinks inside the builds/ directory to avoid the computing hassle involved in the split $JENKINS_HOME.

What we historically had in $JENKINS_HOME/jobs/JOB/lastSuccessfulBuild is also now subsumed by this feature. I initially attempted to create these permalinks in the buidl root directory, but turns out those symlinks aren't the same name as the ID of permalinks, so it doesn't mesh well.

And finally, a test!

Remember the permalink target as symlink (or simple text file) so that
looking that up doesn't cause the walk of the build history.
I think this is more in line with our general preference of making
$JENKINS_HOME useful (than trying to persist cache into a blackbox.)

Having a general purpose in-memory cache could be useful, so I'll see if
I can add that, too, in a way that allows someone to plug different
backend.