Report bad CurrencyUnit input as databind exception rather than UnknownCurrencyException/NPE

[pjfanning]

Problem

CurrencyUnitDeserializer does no token check and no error handling:

final String currencyCode = parser.getValueAsString();
return Monetary.getCurrency(currencyCode);

so provider exceptions escape to the caller instead of a JacksonException:

input read as CurrencyUnit	before
"XYZQ"	javax.money.UnknownCurrencyException: Unknown currency code: XYZQ
{"a":1}	java.lang.NullPointerException: Currency Code may not be null
12	UnknownCurrencyException: Unknown currency code: 12 (silently coerced)

getValueAsString() returns null for structured values, which Monetary then rejects with an NPE — so a caller catching JacksonException sees neither.

The sibling joda-money module's CurrencyUnitDeserializer already does this correctly, so the two modules in this repo disagree on error handling for the same conceptual type.

Fix

Mirror joda-money: handleWeirdStringValue() for an unusable currency code, handleUnexpectedToken() for a non-String token. As a bonus this routes through DeserializationProblemHandler, so applications can substitute a value.

⚠️ Behaviour change

UnknownCurrencyException is now reported as InvalidFormatException (a MismatchedInputException, so JacksonException). The existing shouldNotDeserializeInvalidCurrency test asserted the old type, in both javax-money and moneta; both are updated here.

Flagging explicitly since it is user-visible — happy to drop the handleWeirdStringValue half and keep only the non-String-token fix if you would rather preserve UnknownCurrencyException for 3.x.

Tests

Updated shouldNotDeserializeInvalidCurrency (×2 modules) plus new cases for number/object/array input.

javax-money 138 tests and moneta 140 tests all green.