Prototype implementation for invoice rework (tree of items instaed of addhoc code all over the place)
Invoice repair logic (additional partial implementation)
Initial integration of the invoice tree generation and removal of old repair logic in DefaultInvoiceGenerator
Also, disable test testOverdueStagesFollowedWithImmediateChange2 (already disabled in master) and remove old beatrix 'full repair' tests which are not supported anymore.
Temporary commit for invoice tree rework
Implementation of invoice tree logic to handle both creating view of existing items and merging with proposed item list.

There are a few changes introduced from the previous code:
- Full repair code has been deleted -- was only there for regression test purpose
- Pro-ration logic when calcultaing repair items gives a slightly different result-- and i think more accurate
- Handling of invoice item along with repair has also changed

Tree looks stable at this point, but more work (cleanup, refactoring and tests are needed)
Cleanup unsued code from invoice generator
Rework some of the logic for the invoice item tree
Javadoc for the invoice item tree
Merge remote-tracking branch 'origin/master' into invoice2
Fix issue with 1.6 compiler
Add test for testing code path where we insert proposed items out of order
Fix parent pointer in invoice tree node
Fix issue in rebalance
Initial unit tests for NodeInterval class
Code review integration
- Introduce tree walker
- Fix item adjustement ordering problem
- Rework ItemsInterval
Revert walkChildren method introduced in NodeInterval
Rework the NodeInterval class to abstract the custom logic and leave that class very generic.
Add unit tests for NodeInterval
NodeInterval and other invoice tree related classes rework; in particular:
- Fix search apis and add unit tests
- Add method to walk the tree and build json serialization on top of it.
- Other renaming
Minor edit for code review integration of invoice tree code
Invoice fix to address issues related with leading pro-rations.

In the case of billingPeriod different than MONTHLy the current code would do an initial leading pro-ration to the billCycleDate within
the current or next months. Those would cause different issues as documented in #57, #146 and #160.

The new logic will compute the longest leading pro-ration and as a side effect will address those issues.

Fixes #57, Fixes #146, Fixes #160
Fix a bug in calculation of firstBillingCycleDay.

Add unit tests of that method to verify through various case scenarios that it computes the right date.
Merge branch 'invoice2'
Update to version 0.9.0-SNAPSHOT