TypeChangingRangeChecking decorator throws boost::numeric::{postive|negative}_overflow in preWrite

If the exposed type is smaller than the wrapped type, Trying to write a value that exceeds the limits of the wrapped type will cause preWrite() to throw a boost::numeric::positive_overflow or ::negative_overflow.

This violates the TransferElement specification

If we do not declare it obsolete completely, the RangeChecking type should check type sizes on construction depending on its direction:

• rw is illegal
• ro widens the type from target type to decorator type (Example: target is uint8_t, decorator is int)
• wo narrows the type from target type to decorator type (Example: target is double, decorator is float)

such that range issues during the runtime cannot happen.

Start by tracing TypeChangingRangeChecking and RangeChecking through preWrite(), then consult the TransferElement specification referenced in the issue. Check how rw, ro, and wo directions handle target and decorator type sizes; done means invalid combinations are rejected at construction and runtime range errors do not produce the reported boost::numeric overflow exceptions.