Created using spr 1.3.7

Created using spr 1.3.7

[skip ci]

`absl::StatusOr::status` allows extraction of the status associated with
a StatusOr value. That can also be used to check whether the StatusOr
has a value or not.

This makes sure code like this is checked properly:

```cpp
int target(absl::StatusOr<int> SOR) {
  if (SOR.status().ok())
    return *SOR;
  return 0;
}
```

Created using spr 1.3.7

This reverts commit eed8d3aa4aa6efe01fcf7bd56015b671f5f18e29.

Reverts llvm/llvm-project#162932

Failed Tests (1):
  Clang-Unit :: ./AllClangUnitTests/failed_to_discover_tests_from_gtest

Created using spr 1.3.7

This model implements a dataflow analysis for reporting instances of
unchecked use of absl::StatusOr values. It makes sure that every use
the value of a StatusOr object is dominated by a check that the
StatusOr object is ok.

This is an example of code that will be flagged by the analysis:

```cpp
int f(absl::StatusOr<int> SOR) {
  return SOR.value();
}
```

This is an example of code that will not be flagged by the analysis:

```cpp
int f(absl::StatusOr<int> SOR) {
  if (SOR.ok())
    return SOR.value();
  return 0;
}
```

This model has successfully been used by Google for some time now.

This is the initial commit that adds the simplest possible model, that
only models calls to `ok()` and checks for unsafe accesses. I will add
more fidelity to the model in follow up changes.

The test setup is notable in that it has an extra indirection. This is
because we have an internal model that extends the model we intend to
upstream, in order to model special constructs only found in our code
base. The parametrized test allows us (and anyone who chooses to do
this) to make sure our extensions do not break the base functionality.

RFC:
https://discourse.llvm.org/t/rfc-abseil-unchecked-statusor-use-check/87998

Created using spr 1.3.7