Extraction: project-level .archignore exclusions

[TristanKruse]

Context

Generated code, migrations, vendored fixtures, and other deliberately out-of-scope files currently
require exclusions to be repeated in Ruby test code. ArchUnitPython supports a root-level
.archignore; Ruby should add the same repository-owned configuration concept using its existing
exclude-pattern semantics.

Goal

Load project-wide architecture exclusions from .archignore without executing repository code,
weakening cache correctness, or allowing the configuration file to escape the project boundary.

Starting approach

• Read only .archignore at the detected project root.
• Support blank lines, # comments, existing glob syntax, root-anchored patterns, path patterns,
  and directory patterns ending in /.
• Merge file patterns with default exclusions or caller-supplied exclusions; an explicit empty
  exclusion list still disables defaults but not repository-owned .archignore entries.
• Resolve exclusions centrally so graph extraction and file-based metrics see the same source set.
• Bound the configuration read (1 MiB is a generous starting ceiling), decode UTF-8 defensively,
  and never follow an .archignore symlink outside the project root.
• Include the effective normalized patterns in the graph-cache key so editing .archignore
  invalidates the appropriate graph.

Negated gitignore patterns (!pattern) are not required in the first version and should be
documented as unsupported rather than approximated incorrectly.

Acceptance criteria

• Missing .archignore preserves current behavior exactly.
• Comments, blank lines, files, directories, globs, and leading / anchoring have cross-platform
  fixture coverage.
• Ignored files receive no self-edge, cannot become dependency targets, and are absent from
  file-based metrics.
• Explicit exclude arguments and .archignore compose deterministically without mutating callers.
• Same-process edits to .archignore cannot return a stale cached graph.
• Invalid UTF-8 does not crash extraction; oversized or project-escaping configuration fails with a
  clear user-facing error.
• The parser never executes target code and does not read outside the project through symlinks.
• README, current limitations, and generated API documentation describe the exact syntax and the
  lack of negation support.