apply/lambda Semantics

1. Nullary metafunction classes are now consistent with all other metafunction classes, rather than being identical to nullary metafunctions:

   Nullary...	Before	Now
   Metafunction	f::type	f::type
   Metafunction class	c::type	c::apply<>::type or c::apply::type [7]

   This fixes a flaw in the metafunction class/metafunction algebra that long has been a major source of other inconsistencies throughout the library.

2. The apply metafunction now automatically invokes lambda on its first argument. For example, the following is well-formed now:

   typedef apply< plus<_1,_1>, int_<2> >::type four;
   

   apply_wrapn auxiliary metafunctions are available for rare cases when it's crucial to eliminate the small overhead associated with lambda expressions while still avoiding various compiler bugs known to cause problems with the obvious f::template apply<...>::type syntax.

3. The lambda implementation for broken compilers has been reworked to emulate the semantics of the full-fledged version as closely as possible; consequently, any code out there that was taking advantage of the semantic quirks of less complete emulation in the previous release may stop working with the new one.

To get a detailed picture of the new apply/lambda semantics, please see the test case at http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/mpl/test/apply.cpp?view=markup and the corresponding sections of the MPL reference manual.

[7]	The second form is available only on fully conforming compilers.