Experimental branch for version 2.0 proposition
Experimental version of extremly fast cobertura (1-2 orders of magnitude). The net.sourceforge.cobertura.instrument package has been rewritten.

Additional benefits:
 * Speed, speed, speed
 * It is extremly close to supress requirement that *.sar file created during instrumentation is needed during runtime. In fact the file is now created
only for backward compability.
 * SwitchFunctionalTest works now. Some simillar fixes to coverage in other areas.
 * I think that the new code is cleaner.

Drawbacks:
 * To count hits I use in this implementation just:  int[] hits;
   and to register hit I use: hits[...]++;
   It is extremly fast, but not exactly thread safe. There will be no 'exception' thrown or other problems, but we can
   miss some hits (tests show that it is <5% of hits). But it is guaranted that if there is at least one hit, it will be
   registered. So it does not affect coverage, so seams to be acceptable. If required an exact-thread-safe mode can be implemented
   (but usege of AtomicIntegerArray causes significant (5-10 times) performance decrease - but still is faster then cobertura 1.9.4+).

TODO:
 * ignore and ignore trival functionality has not been merged yet
 * exact-thread-safe mode ?
 * The code need more comments and to be cleaned
 * The code need more tests
Comments and code-style fixes
Marged changes for: Add failonerror to <cobertura-instrument> (mostly just for testing).
Code cleanup. Created separate packages for instrumentation passes. Cleaned names.
Both: FastArrayCodeProvider && AtomicArrayCodeProvider (slower, but returns exact number of hits in multithread environment) are ready to work.
* Added support for --ignoreTrivial in new instrumenter
* Added support for --ignoreMethodAnnotations in new instrumenter
* Added flag --threadsafeRigorous to switch between fast and slow (but strict in terms of thread-safety) mode
Fixed some warnings (we require java 1.5 so we should use generics)
Ignored classes affected reports (and summary of the coverage). Fixed.
Fixed bug connected to method size limit in Java (64kb) - classmap was too long
Integration test for really long class support.
Instrumented code uses java.util.logging instead of System.out....
Added performance test.

Results in my environment:
    Run without instrumentation:                        Test took:  46.795 milis
    Run with instrumentation (not threadsafe-rigorous): Test took: 181.853 milis
    Run with instrumentation (threadsafe-rigorous):     Test took: 547.401 milis
Added performance test.

    Results in my environment:
        Run without instrumentation:                        Test took:  46.795 milis
        Run with instrumentation (not threadsafe-rigorous): Test took: 181.853 milis
        Run with instrumentation (threadsafe-rigorous):     Test took: 547.401 milis
Change .classpath so Eclipse will copy the html files from the src to the bin directory.   This way the functional tests that try to create the html report will not fail.
IgnoreTrivialFunctionalTest now runs an HTML report and makes sure some of the html files are created.
Show information about more files on the html report. Fixes the test by John.
Removed code that required java 1.6.
string.isEmpty() <==> string.length() == 0.
Change .classpath so Eclipse will copy the html files from the src to the bin directory.   This way the functional tests that try to create the html report will not fail. (I tried to do this the last time I changed .classpath, but I did not realize you have to enumerate all the file types you usually get by default)