[analyzer] Always derive a CallEvent's return type from its origin expr.

Previously, we preferred to get a result type by looking at the callee's
declared result type. This allowed us to handlereferences, which are
represented in the AST as lvalues of their pointee type. (That is, a call
to a function returning 'int &' has type 'int' and value kind 'lvalue'.)

However, this results in us preferring the original type of a function
over a casted type. This is a problem when a function  pointer is casted
to another type, because the conjured result value will have the wrong
type. AdjustedReturnValueChecker is supposed to handle this, but still
doesn't handle the case where there is no "original function" at all,
i.e. where the callee is unknown.

Now, we instead look at the call expression's value kind (lvalue, xvalue,
or prvalue), and adjust the expr's type accordingly. This will have no
effect when the function is inlined, and will conjure the value that will
actually be used when it is not.

This makes AdjustedReturnValueChecker /nearly/ unnecessary; unfortunately,
the cases where it would still be useful are where we need to cast the
result of an inlined function or a checker-evaluated function, and in these
cases we don't know what we're casting /from/ by the time we can do post-
call checks. In light of that, remove AdjustedReturnValueChecker, which
was already not checking quite a few calls.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163065 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Treat all struct values as regions (even rvalues).

This allows us to correctly symbolicate the fields of structs returned by
value, as well as get the proper 'this' value for when methods are called
on structs returned by value.

This does require a moderately ugly hack in the StoreManager: if we assign
a "struct value" to a struct region, that now appears as a Loc value being
bound to a region of struct type. We handle this by simply "dereferencing"
the struct value region, which should create a LazyCompoundVal.

This should fix recent crashes analyzing LLVM and on our internal buildbot.

<rdar://problem/12137950>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163066 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Future-proofing r163012 (nameless functions and RetainCountChecker)

Any future exceptions need to go INSIDE the test that checks if the
IdentifierInfo is non-null!

No functionality change. Thanks for the review, Ted.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163067 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Don't attempt to create a floating-point value of "1" for ++/--.

The current logic would actually create a float- or double-sized signed
integer value of 1, which is not at all the same.

No test because the value would be swallowed by an Unknown as soon as it
gets added or subtracted to the original value, but it enables the cleanup
in the next patch.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163068 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Disallow creation of int vals with explicit bit width / signedness.

All clients of BasicValueFactory should be using QualTypes instead, and
indeed it seems they are. This caught the (fortunately harmless) bug
fixed in the previous commit.

No intended functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163069 91177308-0d34-0410-b5e6-96231b3b80d8