Generalize implementation of ImportsResolver to allow imports from arbitrary npm packages

[jjohannes]

Why is it needed?

This came out of a discussion with @rbair23. We would like to use this plugin to compile contracts like this one:

pragma solidity ^0.8.22;

import { OFT } from "@layerzerolabs/oft-evm/contracts/OFT.sol";
import { Ownable } from "@openzeppelin/contracts/access/Ownable.sol";

contract MyOFT is OFT {
    constructor(
        string memory _name,
        string memory _symbol,
        address _lzEndpoint,
        address _delegate
    ) OFT(_name, _symbol, _lzEndpoint, _delegate) Ownable(_delegate) {}
} 

This uses sol files from @layerzerolabs/oft-evm which in turn uses files from other npm packages (transitive dependencies/imports). This could be solved by somehow allowing to add more import providers as suggested in #77. But then you would need to configure all packages manually that are already declared in the SOL files.

What does this PR do?

The solution proposed in this PR automatically reads all required npm packages, including transitive ones. This is done by changing the setup that is handled by the npmInstall and resolveSolidity tasks as follows:

• Add a task extractSolidityImports that extracts all packages required by imports from the SOL files in the project and generates the package.json based on this information. The package.json is the output of this task and it only changes if modules required for the imports change. Which is not often the case. Thus, the next two tasks run seldomly and are UP-TO-DATE most of the time.
• npmInstall downloads the packages and their transitive dependencies.
• resolveSolidity searches through the SOL files downloaded by npm for additional packages that are used to get a complete list for the allowed paths and the path remappings in compileSolidity.

Where should the reviewer start?

This only a proposal at this point. Maybe there are reasons not to do this. I am happy to work on another solution that would allow us to compile contracts as the one shown above.

I haven't changed the documentation in the Readme on this topic yet, but if this is a solution that would be accepted, I will update it as well.

Checklist

• I've read the contribution guidelines.
• I've added tests (if applicable).
• I've added a changelog entry if necessary.

[jjohannes]

@Singleton and @Memoized are problematic in Gradle plugins. Plugin classes are loaded in the Gradle daemon process and are then reused between build runs. Static state is then preserved. I observed here that extractImports still returned old values, even though I changed the source file and the task did run again.