Precedence retrieval error.options.message clobbers lazy validate.js messages that use functions

[rjgotten]

Part of the Validate.js API is the ability to specify a function to serve as the message for a constraint:
https://validatejs.org/#constraints

This delivers the ability for a richer error message feedback.

The can-validate-validatejs bridge clobbers this functionality via a special case that gives precedence to error.options.message - i.e. the original value of the message option - over using the final message from error.error as properly formatted by Validate.js

can-validate-validatejs/can-validate-validatejs.js

Lines 23 to 26 in faaf97b

	errors.push({
	message: error.options.message || error.error,
	related: [error.attribute]
	});

The net result is that we get function() { [native code] } error messages, literally a string conversion of the raw message-as-a-function with which the validator was configured (which I assume has .bind applied to lead to [native code]), instead of the proper formatted error message that Validate.js actually DOES produce, but CanJS tosses out.

Special casing like this should not be necessary as when running the validator, the option fullMessages: false is passed explicitly, which already prevents Validate.js from prefixing the attribute name to the error message - i.e. error.error should always be a clean unprefixed error message.

can-validate-validatejs/can-validate-validatejs.js

Lines 14 to 17 in faaf97b

	var rawErrors = validatejs(values, constraints, {
	format: "detailed",
	fullMessages: false
	});