…tion()`.

So far, if there was a chain of record type prvalues,
`getResultObjectLocation()` would assign a different result object location to
each one. This makes no sense, of course, as all of these prvalues end up
initializing the same result object.

This patch fixes this by propagating storage locations up through the entire
chain of prvalues.

The new implementation also has the desirable effect of making it possible to
make `getResultObjectLocation()` const, which seems appropriate given that,
logically, it is just an accessor.

…xisting storage location.

Without this, llvm#75483 started making tests for an internal analysis fail because
of the following. The framework now generates `RecordValue`s for all `CallExpr`s
that are pravlues of record type; the analysis was also calling
`refreshRecordValue()` for those `CallExpr`s, but some parts of the analysis
were still using the old `RecordValue` because the entry in `LocToVal` had not
been updated.