Resolves:#383,#369

Main Changes:

• Added support forcustom user conditions:
  • ViaJitiOptions andJitiResolveOptions, so, consistently across all programmatic APIs.
  • ViaJITI_CONDITIONS environment variable.
  • Via package.json'sconditions field.
• Added support forsynchronous hooks.

Added Capabilities Examples:

constjiti=createJiti(import.meta.url,{conditions:true});

constjiti=createJiti(import.meta.url,{conditions:['development']});

constjiti=createJiti(import.meta.url,{conditions:{'@scope/**/*':['development']}});

constjiti=createJiti(import.meta.url,{conditions:[{match:['@scope/**/*'],ignore:['@scope/some-specific-package'],values:['development']}]});

• There is fullminimatch support.
• Ifconditions is set totrue, configuration will be read from the nearestpackage.json, relative tocwd.
• Ifconditions is set tofalse, or no configuration is found, then everything should behave like this PR never existed.

Details:

• Createdutils.mjs to group common code for both synchronous and asynchronous hooks.
• Replacedexists withaccess according to most recentrecommended approach.
• Enabledpnpm workspaces for testing with packages.
• Added tests for custom user conditions implementation.
• Updated documentation.

Notes:

• There should not be any breaking changes.
• There should not be any relevant performance changes.
• Madeconditions ->true by default according to thisNode.JS Proposal (see point5 at "The Problem - TL;DR").
• I noticed some differences between outputs fromjiti andnative methods:
  • import() !==jiti.import().
  • createRequire() ->require() !==jiti.import().
  • Staticimport (when using--import jiti/register) !==jiti.import().
• The above happens without this PR and I would be happy to investigate and fix it, if needed, after merging this PR.