major change to field encryption

[Adam Heath <do...@brainfood.com>]

So, based on my findings on field encryption(see previous threads and 
issue OFBIZ-5659), I decided that doing in-place encryption in 
EntityExpr, against rhs, and in-place encryption on GenericEntity, 
really wasn't the correct approach.  The following code patterns break 
when this is done:

==
condition = makeCondition("socialSecurityNumber", EntityOperator.EQUALS, "1234")
people = findByCondition("Person", condition)
// this second line fails, because the rhs above will get doubly encrypted.
people = findByCondition("Person", condition)

person = makeValue("Person", [partyId: "1234"])
person.firstName = "Adam"
person.socialSecurityNumber = "1234"
// this first store encrypts 1234 in-place
person.store()

person.lastName = "Heath"
// this second store encrypts the already encrypted value
person.store()
==

The first code pattern above is extremely troubling; the encryption 
logic, as it stood, would *modify* the incoming condition.  This is so 
extremely bad.  It could even pollute the entity caching system(!).

This fix will changes the encryptFields() and decryptFields() in 
delegator to be no-ops(deprecates them as well), removes all 
encryptConditionFields() from all conditions, and makes SqlJdbcUtil do 
the encrypt/decrypt phases as it's interfacing with PreparedStatement 
and ResultSet.

And, as a bonus, the code size is reduced.

ps: Note, that the findByCondition pattern does not work with current 
trunk, due to the problems outlined in OFBIZ-5659.  I have it working 
locally, and with test cases as well.