Completely custom timeout approach as suggested by dsaff in #727

As #727 is already merged and I therefore think kind of resolved, I created this pull request to avoid forgetting this approach as suggested by dsaff near the end of the conversation to #727. Please note that I also think

The following lines/thoughts are an edited copy of https://github.com/junit-team/junit/pull/742#issuecomment-29959187:

----------------------------
I think that in addition to these 2 steps, it is also necessary:
(3) to allow access to all fields of Timeout (i.e. fTimeout, fTimeUnit and fLookForStuckThread) either via changing its visibility from private to e.g. protected, or via a getter (with e.g. protected visibility) => for now with changed visibility for the sake of less change, what do you prefer?
(4) since FailOnTimeout#createTimeoutException contains some bits of logic that should be re-used instead of being duplicated => it should be called too in the custom overridden method first => then additional nesting of the returned Exception (it may already be a MultipleFailureException) might be needed (to provide either the additional failure context in the test failure, or to provide a hint in the test failure that our custom FailOnTimeout may have provided additional failure context e.g. in the log output or whatever)

I have made the changes and added tests.

(Side note: in case CustomTimeoutTest.infiniteLoopwithLookForStuckThread() is executed before CustomTimeoutTest.infiniteLoop() the full stacktrace on timeout of the second test shows the surviving threads from the first test, which is using InfiniteLoopMultithreaded from the original TimeoutTest => presumably that is not on purpose...)

However, please note that (as I tried to convey in the older pull requests #770 and #772) I am still hoping for "more" allowing to cover these outlined real world use cases (in particular without the risk of missing certain tests).
----------------------------