[ETHEREUM-CONTRACTS] make openzeppelin import path version specific

[d10r]

openzeppelin-contracts stable major version has been v5 for a while.
If a Solidity project using openzeppelin v5 also wants to use the Superfluid protocol, that can result in a conflict.
In order to make that less likely, and to prepare the migration to openzeppelin v5, we change the import path to explicitly contain v4.

[github-actions]

Changelog Reminder

Reminder to update the CHANGELOG.md for any of the modified packages in this PR.

• CHANGELOG.md modified
• Double check before merge

[d10r]

strange failure in autowrap package:

Error (9582): Member "safeTransfer" not found or not visible after argument-dependent lookup in contract ISuperToken.
  --> packages/automation-contracts/autowrap/contracts/strategies/WrapStrategy.sol:65:9:
   |
65 |         superToken.safeTransfer(user, adjustedAmount);

Relevant code in WrapStrategy.sol:

import { SafeERC20 } from  "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
    using SafeERC20 for IERC20Mod;
    using SafeERC20 for ISuperToken;
...
  underlyingToken.safeTransferFrom(
            user,
            address(this),
            underlyingAmount
        );
...
  superToken.safeTransfer(user, adjustedAmount);

Note how the previous safeTransferFrom works.

The compile error could be solved by changing the paths to @openzeppelin/contracts-v4 too here.
But it should work as is too.

[d10r]

finding:

superToken.safeTransfer(user, adjustedAmount);

fails because from the perspective of the compiler, ISuperToken is not type compatible with IERC20 in the context of this package.
That's because the IERC20 imports by ISuperToken and SafeERC20 resolve to different files now (even though there's no difference between them).

Ways to avoid this:

• in autowrap remap @openzeppelin/contracts to node_modules/@openzeppelin/contracts-v4/
• change import paths in autowrap to @openzeppelin/contracts-v4 too. What to do with the dependency in package.json in this case? Omit or use custom path too?

For projects using OZ v5, this type incompatibility cannot be avoided (regardless of this change happening or not). Possible workaround: cast to a type imported from v5.