diff: select all root nodes by default

better fix for e770f02
Initial implementation of structural types

We infer structural types based in the usages of the attributes of a
function parameter. Currently we do it by inspecting only the body of
the function and ignore passing the parameter to subsequent calls.
Fix code completion and find usages for implicitly inferred types

Recently introduced structural types affect code insight for implicitly
inferred types. If an expression is of a structural type that has been
inferred from attributes usage then we should add implicit results we
used to infer for it before the introduction of structural types.
Suppress type and attribute inspections for structural types

Currently the type checker is not capable of checking structural types.
We have to disable these inspections until we update our type cheker.
Infer structural types for function parameters from nested calls

Using a parameter as an argument of a nested function call augments the
attribute contract for that parameter with attributes used during the
call. We use the available TypeEvalContext to keep the analysis of
nested calls fast.
Don't treat structural types as unknown

Since we are going to check structural types properly, we should stop
treating them as unknown. It requires a few modifications in the places
where the PyTypeChecker.isUnknown() check was enough.
Don't expect the type checker to check inferred structural types against other structural types
Fixed searching for nested attributes access for structural types

There was a missing check if an argument of a nested function call is
really a reference to the parameter we're processing. It resulted it
adding unrelated attributes to structural types.
Don't check structural types against the types from 'abc'

Proper structural checking for the types from 'abc' is not implemented.
Initial type checker for structural types

It checks structural types against other structural types and class
types.
Cleanup (javadoc)
Cleanup (unused import; too specific class)
Fixed callable inspection for usages-based structural types

We suppose that a structural type inferred from the usages of
attributes is callable, it's just another aspect of its attribute-based
contract.

We don't add '__call__' to the type at the moment, but it might be a
better solution. Some other special methods like '__getitem__' are
processed correctly because they are resolvable references to
appropriate methods.
Merge branch 'master' into python-structural-types

Conflicts:
	python/testSrc/com/jetbrains/python/inspections/PyTypeCheckerInspectionTest.java
Fixed collecting wrong '__contains__' attribute for structural types

The 'x in y' expression implies that 'y' has the '__contains__'
attribute, while our references in qualified expressions tell that
the 'x' references the name '__contains__'. In order to fix this we have
to treat the operators with a receiver on the right side of the
expression differently.
Don't add untyped completion variants for structural types

They mostly duplicate each other for scopes of local functions. For
structural types we add only implicit variants obtained from a
name-based class guess.

The test data for seenMembers has been updated in order not to clash
with structural types completion.
Use separate type eval context for code completion

We used to have context.allowLocalUsages() for permitting a code
analysis to guess types from file-local function calls. This analysis
mode came into conflict with the new structural types, since they both
provided types for function parameters. Another problem is that the user
used to see the types inferred from local calls in the documentation
pop-up and it was not clear where did they come from.

The solution is to introduce a new type eval context for code completion
only named TypeEvalContext.codeCompletion() and allow file-local call
based type inference only in this context.
Don't collect attributes conditionally accessed inside 'if' statements

It's a workaround for false positives in type checking if a function
expects its parameter to be of various types depending on some
condition we couldn't analyze statically. Another possible source of
false positives is try-except statements, but they are less likely, so
we ignore them at the moment hoping that benefits from collecting
the attributes of a parameter inside try-except will beat losses in
the amount of false positives.
Moved overridesGetAttr to PyTypeChecker
Don't check class types with '__getattr__' against structural types

Classes with '__getattr__' and '__getattribute__' may have any
attributes defined by the user at runtime.