ReentrancyGuard should expose the `_status` publicly

🧐 Motivation

An increasingly common security issue is "read-only reentrancy". These issues arise when protocol A relies on the state of protocol B, and protocol B's state can temporarily be manipulated. Even if protocol B uses reentrancy guards to protect against this manipulated state, protocol A can't inspect B's reentrancy guard itself, which can make integration nearly impossible. Some recent examples of this issue include a vulnerable integration with Euler and vulnerable integrations with Curve. In the case of the Curve integration bugs, the only fix for the vulnerability was to add an otherwise unnecessary call to a state modifying function that has a nonReentrant guard, which is a very hacky fix. In some cases, there might not be a good nonReentrant function that can be called "for free", so the mitigation would involve try-catching a call to such a function and inspecting if the error message is "ReentrancyGuard: reentrant call", which would be an even uglier fix.

📝 Details

It would make much more sense for ReentrancyGuard.sol to expose the _status variable publicly in some way. A simple fix for this would be to mark the internal _reentrancyGuardEntered function as public:

- function _reentrancyGuardEntered() internal view returns (bool) {
+ function reentrancyGuardEntered() public view returns (bool) {
     return _status == _ENTERED;
 }

Start in contracts/security/ReentrancyGuard.sol at _reentrancyGuardEntered and review how _status and the guard constants are used. Make the reentrancy state externally inspectable without changing guard behavior, then verify the existing ReentrancyGuard coverage still passes and confirms the new public access.