changed comparison to NO_EXPECTED_TYPE to
 'noExpectedType' invocation
added 'isDenotable' flag to TypeConstructor
added UNKNOWN_EXPECTED_TYPE, NumberValueTypeConstructor

analyze function arguments with UNKNOWN_EXPECTED_TYPE
(for several times in different traces yet)

for number literals create type with NumberValueTypeConstructor with exact value,
transform it to the corresponding type when resolve arguments (expected type is known)

doesn't work properly for if, elvis operator, etc. (throws exceptions)
process number value types properly in constraint system

the case when type parameter has number value types (constants) as lower bounds
should be handled specially, because upper bound for primitive number types is 'Number',
but by default we want Int (or Long)
added diagnostic message tests to ensure that number value types don't appear in error messages
added DoubleValueTypeConstructor

no need to store exact value in IntegerValueTypeConstructor, it was removed
changed way to compute common supertype for number types

(using only supertypes, not exact value)
added todo comment
report ERROR_COMPILE_TIME_VALUE for constants instead of TYPE_MISMATCH

(functionality returned)
report only 'The value is out of range'

not 'An integer literal does not conform to the expected type Int/Long'
refactoring: extracted methods

from 'completeNestedCallsInference'
added test for nontrivial nested calls
removed code duplication

extracted 'getTypeInfoWhenOnlyOneBranchIsPresent'
check all upper bounds even if there are some error types in bounds

for cases like 'val l:List<Int> = id(newList())'
List<???> is a lower bound for id's type parameter here
added 'getDataFlowInfoForValueArgument' to ResolvedCall interface
added ability to resolve call with uncustomary tracing strategy

(necessary for special 'tracing for if')
refactoring: extracted method 'reportTypeInferenceExpectedTypeMismatch'

to reuse it later from 'tracing for if'
changed required/found types order in message to synchronize it with 'TYPE_MISMATCH' error
resolve 'if' as call when expected type is unknown
use data flow info in constraint system

intersect data flow value possible types
add intersection type (or exact type for the most cases) as a lower bound to constraint system

always get common super type for intersection type as a result
(avoid returning it, even in error messages)
added DataFlowInfoForArguments

data flow info for argument depends on previous argument analysis
special interface was added to support case with argument types inference
and 'if' (with special data flow info for then and else arguments)