Bug 574883 - Job.getJobManager().join(family) doesn't wait for a
re-scheduled job

1. Do not restart the Job (in another thread) before it's notifications
have been processed by the join listener. That is also wanted for other
Listeners since they should be able to decide if the Job
should start again (see JobTest.testCancelFromAboutToRun(),
JobGroupTest-testShouldCancel_4()) and could use the information about
how the previous job ended.
Previously it was possible that the Job notifications was send and
processed in different threads and - since not synchronized - in
arbitrary order. Especially a job
could restart in another worker thread before the notification was
processed that previous job execution was done.
Still the events are processed in different threads, but the
notification order is fixed.

2. Perform reschedule while holding lock to prevent unsynchronized
moments where Jobs that are rescheduled are neither running, sleeping or
waiting

3. Synchronize read/write access to InternalJob.flags to atomically
change bits.

The benefit is shown by JUnit Test Bug_574883.testJoinLambdaOften().
Basic functionality is tested by JobTest, JobGroupTest

The join() implementation is still not 100% bullet proof but the chance
of false joins are reduced by some reasons.