Generate skeletons for binary modules in buildout eggs (PY-11932)

(cherry picked from commit d535a92f47e01239151970c68c75d0638d62b5f9)
Don't suggest live template inside string literals (PY-12349)

The previous fix was unsuccessful since we ignored only string literal
elements but not their subparts.

(cherry picked from commit 7b5dfcfd61faa3f9012cefdc25c4131ccd122480)
PY-11932 Put nulls for unresolved class types in MRO

Some of the ancestor class-like types may be unresolved. The best we
can do is to put nulls for all the unresolved classes to appropriate
places inside the MRO chain. What we used to do in this case it return
the empty sequence of the ancestors.

(cherry picked from commit b37b0440d06989a4612262a1574678ffa8981650)
Fall back to old-style ancestors if C3 MRO fails and there are unresolved ancestors (PY-11401)

If the C3 MRO algorithm fails and the old-style ancestors algorithm
tells that there are unresolved ancestors, we return a single 'null'
ancestor as a sign that we don't know who the ancestors really are.

If there are no unresolved ancestors, then we fall back to the
old-style ancestors algorithm in order to make resolve work. A future
inspection for detecting incorrect MRO may warn the user about this
situation.

(cherry picked from commit 19e9c38a86c4e9bd694ee0bbcd86afc69f08af19)
If mro() is overridden in metaclass, use normal MRO + unresolved ancestor (PY-11401)

We cannot evaluate the result of an overridden mro() method, so we
don't know the actual MRO chain. Let's assume that MRO is almost the
same as without this override and add an element of uncertainty by
appending a fake unresolved ancestor type to the MRO chain. Doing so
results in, for example, the unresolved references inspection ignoring
unresolved references for such a class.

(cherry picked from commit 645bd3a1b27bb3c3a45e557350fb3b81da1ab52a)