Resolves: #383, #369

Main Changes:

• Added support for custom user conditions:
  • Via JitiOptions and JitiResolveOptions, so, consistently across all programmatic APIs.
  • Via JITI_CONDITIONS environment variable.
  • Via package.json's conditions field.
• Added support for synchronous hooks.

Added Capabilities Examples:

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

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

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

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

• There is full minimatch support.
• If conditions is set to true, configuration will be read from the nearest package.json, relative to cwd.
• If conditions is set to false, or no configuration is found, then everything should behave like this PR never existed.

Details:

• Created utils.mjs to group common code for both synchronous and asynchronous hooks.
• Replaced exists with access according to most recent recommended approach.
• Enabled pnpm 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.
• Made conditions -> true by default according to this Node.JS Proposal (see point 5 at "The Problem - TL;DR").
• I noticed some differences between outputs from jiti and native methods:
  • import() !== jiti.import().
  • createRequire() -> require() !== jiti.import().
  • Static import (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.