feat: add allow options to no-empty-definitions

[TKDev7]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request?

This pull request adds support for the allowDefinitions option to the no-empty-definitions rule, allowing users to specify definition identifiers that should be intentionally allowed to be empty. It also adds an allowFootnoteDefinitions option to let users specify footnote identifiers that should be allowed to be empty.

What changes did you make? (Give an overview)

• Modified the rule logic to skip reporting empty definitions and footnote definitions whose identifiers are included in the respective allow lists.
• Added tests to verify the new options work as intended.
• Improved documentation to describe the new options and provide usage examples.

Related Issues

Fixes #436

Is there anything you'd like reviewers to focus on?

[Copilot]

Pull Request Overview

This PR enhances the no-empty-definitions rule by adding two new allow lists and updating tests and docs to cover those options.

• Introduce allowDefinitions and allowFootnoteDefinitions options, update schema and defaultOptions.
• Modify rule logic to skip reporting for identifiers in the allow lists.
• Add new test cases and update documentation with examples for the new options.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
tests/rules/no-empty-definitions.test.js	Added valid/invalid cases to verify allowDefinitions and allowFootnoteDefinitions.
src/rules/no-empty-definitions.js	Extended schema, defaultOptions, and rule logic to honor the new allow lists.
docs/rules/no-empty-definitions.md	Documented the new options with configuration examples.

Comments suppressed due to low confidence (1)

src/rules/no-empty-definitions.js:11

• The JSDoc tag @import is nonstandard. Consider using a proper @typedef import syntax, e.g.: @typedef {import("../types.js").MarkdownRuleDefinition} NoEmptyDefinitionsRuleDefinition.

 * @import { MarkdownRuleDefinition } from "../types.js";

[Copilot]

Because ESLint does not deep-merge defaultOptions with a user-supplied options object, users who specify only one property will lose the defaults for the others. Consider destructuring context.options[0] with in-function defaults (e.g., const { allowDefinitions = ["//"], allowFootnoteDefinitions = [], checkFootnoteDefinitions = true } = context.options[0] || {};) to ensure all defaults apply even when partial options are provided.

[Copilot]

Using optional chaining here assumes allowDefinitions is always provided via defaultOptions. If a user passes an empty object, this will be undefined. You may want to explicitly default to an empty array to avoid unexpected behavior: new Set(context.options[0]?.allowDefinitions || []).

Suggested change

	const allowDefinitions = new Set(context.options[0]?.allowDefinitions);
	const allowFootnoteDefinitions = new Set(
	context.options[0]?.allowFootnoteDefinitions,
	const allowDefinitions = new Set(context.options[0]?.allowDefinitions || []);
	const allowFootnoteDefinitions = new Set(
	context.options[0]?.allowFootnoteDefinitions || [],

[nzakas]

Overall LGTM, just left one suggestion. Would like another review before merging.