Add minor version to v3 protocol to allow changes without breaking backwards compatibility

Hi,

As discussed few days ago it would be beneficial if we could change the v3 backend<->client protocol without breaking
backwardscompatibility. 

Here is a working patch that exports a supported_binary_minor constant and a binary_minor session variable and a that
canbe used by clients to enable newer  
features.

I also added an example usage where the array encoding for constant size elements is optimized if binary_minor version
isnew enough. 

I have coded the client side support for binary_minor for jdbc driver and tested that it worked. But lets first discuss
ifthis is an acceptable path forward. 

On 11/25/2011 02:20 AM, Oliver Jowett wrote:
 > Re list vs. always-incrementing minor version, you could just use an
 > integer and set bits to represent features, which would keep it simple
 > but also let clients be more selective about which features they
 > implement (you could support feature 21 and 23 without supporting 22)

I decided not to use a feature flag because when features start to depend on each other we need multiple negotiation
roundtrips until the final feature set can  
be known.
If in your example above the feature 23 depends on server side on feature 22, but the client only requests 21,23. The
servermust inform back that combination  
21,23 is reduced to 21. And if then the client can not support 21 without 23 the final feature set will not contain 21
or23. 

-Mikko