New versioning strategy for optimistic lock: next version value managed by App

With this improvment the next value for the version field used for the optimisic lock strategy can be managed by the application.

**When can be useful?**
Obviously it is useful if we whant different values than the standard and for example:
* using also negative numbers
* using a combination of datetime and progressive number
* mark with the same version all the records touched in a single updating session
* anything that I want to do with my app and can be meaningful for me

**And really can be done something different from standard ways?**
The **base property** that a version column next value must have in order to accomplish his own task is this:
*be different from any value that any other concurrently running client/process/thread/session may have read as current version value for the same record.*
The opposite may sound more clear: if I write the same value that anyone concurrently working with me has read as current version he will find the same version when writing and will think that all is ok.

That told the standard implementations are:
* next version = version + 1: prerfect
* next version = TIMESTAMP: not so perfect but someone can live with

This two obviously respects the **base property** but the point is that they are not the only ones. Some examples:
* increment by two: not so strange but different
* increment up to 1000 and then restart from 0
     * if I'm sure that every session will end before other 1000 session has occourred it can work
* use a GUID as version so I will "never" finish the possible values
* use strings
  * wisely: knowing the "base property"
* use values from an autogenerated ID of other table (generated for each updating session)