Improve id resolution

[lukastaegert]

This PR contains:

• bugfix
• feature
• refactor
• documentation
• other

Are tests included?

• yes (bugfixes and features will not be merged without tests)
• no

Breaking Changes?

• yes (breaking changes will not be merged unless absolutely necessary)
• no

List any relevant issue numbers:
Resolves #2811

Description

This cleans up, refactors, fixes and extends the resolution of static and dynamic module ids.
It includes:

Fix existing this.resolveId plugin context function

Before when plugins returned false or the new object form in their resolveId hook, this function would also return false or an object. This is changed now in that this utility function will now always return the resolved id as a string or null if the id cannot be resolved. The documentation is adjusted as well.

Add new this.resolve plugin context function and mark this.resolveId and this.isExternal as deprecated in the documentation.

With the new object form, there are some situations that are very hard to manage via the existing utility functions. Most notably, this.isExternal did not take ids into account that were marked as "external" by plugins.

To that end, there now is a new this.resolve(source, importer): Promise({id: string, external: boolean}) utility function that resolves to an object and can be used to replace both this.resolveId and this.isExternal.

The old hooks have only been marked as deprecated in the documentation for now. I made notes here https://github.com/rollup/rollup/projects/2 and here https://github.com/rollup/rollup/projects/3 to deprecate and remove them in the next major versions.

Refine resolveDynamicImport hook

The hook has been refined in several important aspects and the documentation has been updated accordingly:

• if the specifier is not a string and the hook returns a string, this string is used to replace the import argument (existing behaviour)
• if the specifier is not a string and the hook returns false or all hooks return null, the import is retained as it is without a warning (existing behaviour)
• if the specifier IS a string, the hook behaves exactly like this.resolveId:
  • returned strings will be interpreted as module references to be included in the graph (existing behaviour)
  • if all hooks return null, the specifier is passed to the normal resolveId hook (existing behaviour)
  • if the module is not resolved by either hook and the specifier was absolute, the same warning as for resolveId is shown (NEW)
  • if the module is not resolved by either hook and the specifier was relative, the same error as for resolveId is thrown (NEW)
• Independent from whether the specifier is a string, the hook can always return an {id, external} object which will always be treated as a module reference (NEW). This allows resolving truly dynamic imports to modules in the graph.