Patch for issue #421: Multiple levels $expand

In the original code, only one level of $expand is guaranteed to work.
Depending on the cardinality of the expanded relationships, there is a
chance to return null in higher levels. This is also admitted in the
comment at line 417 of the original
restlet/ext/odata/internal/EntityContentHandler.java. This change set
has been checked on version 2.1-RC5. Needs testing before release,
because the complexity of the framework. I would suggest complete
rewrite of these files at some point, because they would not only be
more manageable but also because they contain a design decision wich
causes the processing of the OData stream to have computational burden
O(n * d^2), where n is the number of XML elements in the stream and d is
the maximum $expand depth. This d^2 could be avoided in a new design.
The supplied code probably needs reformatting, as i have different code
formatting conventions.
Patch v2 for issue #421: Multiple levels $expand

This is the same patch as before, only the formatting of the code has
changed to meet the Restlet conventions. A few comments were also added.
The original description follows.

In the original code, only one level of $expand is guaranteed to work.
Depending on the cardinality of the expanded relationships, there is a
chance to return null in higher levels. This is also admitted in the
comment at line 417 of the original
restlet/ext/odata/internal/EntityContentHandler.java. This change set
has been checked on version 2.1-RC5. Needs testing before release,
because the complexity of the framework. I would suggest complete
rewrite of these files at some point, because they would not only be
more manageable but also because they contain a design decision wich
causes the processing of the OData stream to have computational burden
O(n * d^2), where n is the number of XML elements in the stream and d is
the maximum $expand depth. This d^2 could be avoided in a new design.
The supplied code probably needs reformatting, as i have different code
formatting conventions.
Fix for #664: Custom mapped fields may fail

After applying the patch #661 for issue #421 (possible failure of
multiple levels $expand), i ran the standard unit tests supplied by
Restlet. The unit test
modules/org.restlet.test/src/org/restlet/test/ext/odata/ODataCafeCustoFeedsTestCase.java
failed in method testQueryCafesExpandContact because it failed to read a
custom mapped field of an expanded entity. All other methods, which also
contained custom mapped fields, succeeded.

The original code passed this test, but this success was a matter of
chance: There was a double fault which counter-balanced the faults in
$expand logic. This fault of the original code can be brought to surface
as described in issue #664: The success of reading a custom mapped field
depends on its position relative to the 'content' element in the OData
XML stream.

This patch fixes both problems at once: It provides insensitivity to
custom mapped field relative position, and it also fixes the previous
patch #661 to read mapped fields in expanded entities corectly.

This patch should be applied after applying patch #661.
Added unit test for #661: Multiple levels $expand

This commit adds unit test for deep and multiple $expand and registers
it in the main test suite. Since the preexisting "Café" testing model is
too small for deep $expand tests, a medium-size model of 50 entities is
included. The model is mocked using the same technique as "Café".
Removed comments

Removed commented code used during test development.
Warning cleanup and comments fix

Cleaned up unneeded imports from generated OData service proxy. Removed
actual URL from the comments in the generated proxy.
Integration Emmanuel Liossis patch.