Resolve transient value onBlur

[DovydasNavickas]

Terminology:
"Resolve value" means if transientValue is defined, we set it to undefined and then field render value comes from a currentValue. Thus, transient field value gets resolved into a proper one.

Pre-problem:
NumberInput is based on TextInput, thus its currentValue type is number while defaultValue and initialValue are of type string. This happens because NumberModifier parses TextInput value and changes its type string -> number.

Problem:
Field's pristine status is calculated by comparing currentValue with initialValue and taking into account whether the transientValue is defined. Thus, when initialValue of TextInput is of type of string and currentValue of NumberInput is of type number, even though the value did not change from the initial one, "0" and 0 are still not strictly equal to each other.

Possible solution:
For all fields resolve value on blur.

Pros:
Value will be resolved universally, not leaving situations when form is submitted, field is unregistered and/or re-registered right away with transientValue present. Aforementioned situations will be easier to solve and will have less corner-cases.

Cons:
For most simple fields, this would make mechanisms easier, but complex fields will have limitations that cannot be easily solved or even result in bad UX.

E.g. There is a field with a value containing 3 values from the sliders in a tuple:

[number, number, number]

And sliders have values between 1 and 3:

1    2    3
1    2    3
1    2    3

If all values coming form the combination of sliders are correct, it's all nice and fun.

But if some of the resulting values are incorrect, there might be interesting situations.

Let's assume that values [1,1,1] and [1,2,2] are correct ones, but [1,2,1] and [1,1,2] are not.

Then, for values [1,1,1] to be changed to [1,2,2], they need to go though one of these progressions:
[1,1,1] -> [1,2,1] -> [1,2,2]
Or:
[1,1,1] -> [1,1,2] -> [1,2,2]

Remember those middle values? They're incorrect. And thus, they would become transientValue instead of going straight to a currentValue. And if we resolve value on blur, value [1,2,2] will be impossible to enter using mentioned sliders, because:
[1,1,1] -> [1,2,1] --(blur)--> [1,1,1]

[1,1,1] -> [1,1,2] --(blur)--> [1,1,1]

Thus, no matter which slider we change, value resolving will change it to a currentValue and user will not see the desired change and will not be able to enter a desired resulting value.

Result:
Resolving value on blur is not an option.