Fix EntityExpr encryptConditionFields; in normal use, lhs would never be
a String, because it would end up being wrapped in an EntityFieldValue
object.  The only way it would be a String is during incorrect
Freemarker lookups(which no longer happen, as the
EntityCondition.makeCondition factory pattern is now in use).

With this fix in place, EntityExpr can finally start encrypting it's
field values, so that direct matching on encrypted fields can work.

This is part one to fix OFBIZ-5959: Person.socialSecurityNumber can't be
used for findByAnd.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1604967 13f79535-47bb-0310-9956-ffa450edef68
Change encrypt=true fields to no longer have a pre-pended salt value.
This is done by just setting the length of salt bytes to 0, but still
having a length byte prepended.

Add a feature to allow for certain fields to actually have a salt
prefix.  This is enabled by setting encrypt=salt in the entity
definition.

This change is slightly incompatible with existing code.  Old database
values will continue to be decrypted correctly.  However, newly
encrypted values will no longer have a salt prepended, while originally
they would.  This shouldn't be a problem in practice.

This change, along with the previous commit, finally allow for direct
lookup of encrypted values.  However, already stored values will not be
found.  To fix those, each database row will have to be read in by
ofbiz, then immediately written back out.

This is part two to completely fix OFBIZ-5959:
Person.socialSecurityNumber can't be used for findByAnd.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1604968 13f79535-47bb-0310-9956-ffa450edef68