moved ResolveMode, ResolutionResultsCache
 from CallResolutionContext to ResolutionContext
analyze all function arguments without expected types

arguments are now analyzed for several times, for each resolution candidate;
the goal is to analyze them once

todo (don't work properly):
 - number literals
 - if/when expressions
check argument types through complete phase
with right data flow info
extracted 'getResultingCall' method
rewrote 'getResultingType' in terms of it
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')