[Improvement] Correct usage of ERC-165

[adam-alchemy]

• ERC-165 is used in some areas with confusing or unexpected results. We should re-evaluate this usage.
• Dependency interface id checks
  • Part of the checks that the installation workflow does is ensure that the addresses of provided dependency functions matches the dependent plugin’s expectation. This isn’t all that useful, however, since the migration to “fixed names” for associated functions as defined in IPlugin. Any “internal” functions routed to via the uint8 functionId field does not contribute to the ERC-165 interface ID, so this check doesn’t provide anything. In fact, it can be bypassed by setting the dependencyInterfaceId to IPlugin, allowing anything to be provided.
• There may be a disconnect between what a plugin reports via supportsInterface and what it actually specifies within the manifest field interfaceIds. There may also be a discrepancy between what the manifest specifies and what it actually causes the account to implement.
• Using the interface check for execute/executeBatch/executeFromPluginExternal to prevent unexpected plugin interactions is expensive, and pollutes call tracers. It may also cause side effects / simulation discrepancies, because a contract is capable of detecting how many times it has been executed via staticcall.

[huaweigu]

Maybe relevant to the last point, some blockchain explorer might have UX issues for userOp that's initiated from account into legacy contracts without 165 support.