WinRT parameters and results typed IReference<T> (nullable values such as IReference<Double>) now take and return plain JS numbers and null.

Problem

• null wasn't passed as a null reference. APIs that read a null IReference<T> as "leave this unchanged" got 0 instead. For example, ScrollViewer.ChangeView(null, offset, null) set the zoom to its 0.1 minimum instead of only scrolling.
• Numbers were passed as the boxed IPropertyValue, not as the IReference<T> interface the parameter's type asks for.
• IReference<T> results came back as wrapped objects, not as the value they hold.

Change

• Parameters: null and undefined pass a null reference. A number is boxed with the typed Create* call and queried for the parameter's IReference<T> IID (generic type arguments substituted). An existing boxed value, such as one from NSWinRT.interop.reference, is passed the same way. The queried interface is held until the call returns.
• Results: method results and property getters typed IReference<T> are read through get_Value and returned as the number (or struct) they hold. A null reference returns null.
• Engines: both the classic engine and the Node-API engine use it.

Tests

cargo test -p runtime --lib --release:

• New test: ireference_parameters_and_results covers DecimalFormatter.ParseDouble/ParseInt (a number, and null for unparsable text) and the ContactDate Day/Month/Year properties (unset reads null; set, negative, cleared with null/undefined, and set from NSWinRT.interop.reference). It passes.
• Whole suite: 148 passed and 11 failed. The same 11 fail on main (the run_on_ui_thread, ui_dispatcher and a few XAML interop tests).

cargo check -p runtime --no-default-features --features napi_engine builds.