Feature Request: Granular Control Modifiers in Context.sol Contract

🧐 Motivation
In the process of developing smart contracts, I've identified a potential enhancement to the Context contract in OpenZeppelin. The goal is to provide more granular control over the execution context, ensuring that certain functions can only be called directly by end-users (Externally Owned Accounts or EOAs) and not by other smart contracts or through proxy contracts. This can be particularly important for functions that deal with sensitive operations or where the intent is to have direct interaction without any intermediaries.

📝 Details
I propose adding three new modifiers to the Context contract:

1. onlyEOAWithoutProxies: Ensures the call is made directly by an EOA and not through any proxies.
2. onlyEOA: Ensures the call is made directly by an EOA, preventing smart contracts from executing certain functionalities.
3. noProxy: Ensures the call is not made through a proxy.

modifier onlyEOAWithoutProxies(address thisAddr) {
        bool cond1 = msg.sender == tx.origin;
        bool cond2 = address(this) == thisAddr;
        require(cond1 && cond2, "Context: call must be direct and without proxies");
        _;
    }

    modifier onlyEOA() {
        require(msg.sender == tx.origin, "Context: caller must be EOA");
        _;
    }

    modifier noProxy(address thisAddr) {
        require(address(this) == thisAddr, "Context: call must not be through a proxy");
        _;
    }

These modifiers provide developers with more tools to control and validate the execution context of their functions, ensuring better security and functionality alignment.
You can find the complete implementation here: https://github.com/1anyway/ValidateContext/blob/main/contracts/Context.sol
I believe these enhancements could be a valuable addition to the OpenZeppelin library, providing developers with more flexibility and security options.

Start by reading the existing Context contract and the proposed implementation in the linked ValidateContext Context.sol file. Review the issue discussion and the security implications of tx.origin and proxy detection before proposing a design. Done means the maintainers agree on the modifier semantics and the change is covered by appropriate contract tests.