fix(commonjs): short-circuit to actual module entry point when using circular ref through a different entry

[danielgindi]

Rollup Plugin Name: commonjs

This PR contains:

• bugfix
• feature
• refactor
• documentation
• other

Are tests included?

• yes
• no

Breaking Changes?

• yes
• no

Description

A friend encountered an issue with the latest version of the redis module,
where there is a circular reference, but one of the internal files references to the main index.js using require('../').
Now commonjs just resolves this to index.js and requires it, but in our case it started a new module/exports context, required index.js, and then attached the result to the export. Which failed, as the exports should already have had a few properties attach by the time the circular ref hit.
Now I brought this even closer to the commonjs implementation - we now store information about the correct target, so the virtual commonjs system will know to actually require the index.js in the first place, and not as a secondary require.
I've also thought of the possibility to do this in the transform - changing the require calls in the source - but this will not work for many cases where the require path is built dynamically.

(Btw, the new circular dependencies support with commonjs@19 fails with this module too. Some cases are just too weird)

[danielgindi]

Something looks stuck in circleci?

[shellscape]

Yeah looks like it. We can safely ignore it.