Refactor: Decouple Operators and Utilities from `__init__.py`

[Rakadeja]

Summary & Motivation

As new features like sanitization and batch exporting were added, the main __init__.py file grew significantly in size and complexity. It was becoming a "monolithic" file, responsible for registration, properties, UI update logic, and all operator execution logic.

This refactor was undertaken to improve the long-term health, maintainability, and scalability of the addon by separating these distinct concerns into their own dedicated files and modules.

"Before" - The Old Structure

Previously, the addon's structure was flat, with the __init__.py file containing the bulk of the application logic:

/BatchFont2Mesh/
├── __init__.py  <-- Contained EVERYTHING (Operators, Properties, Utilities, Registration)
├── dependencies.py
└── ui.py

"After" - The New, Decoupled Structure

The addon has been reorganized into a more robust package structure with clear separation of concerns:

/BatchFont2Mesh/
├── __init__.py      <-- Now acts as a central hub for registration and properties.
├── dependencies.py
├── ui.py
├── operators/       <-- All action classes (Prepare, Generate, Export) are organized here.
│   ├── __init__.py
│   ├── op_prepare.py
│   ├── op_generate.py
│   └── op_export.py
└── utils/           <-- Helper functions and data (like naming sanitization) are stored here.
    ├── __init__.py
    └── naming.py

---

Benefits of this Refactor

This architectural change provides several key advantages:

• Improved Readability: Each file now has a single, clear responsibility. If you need to edit the "Generate" logic, you only need to open op_generate.py.
• Easier Maintenance: Bugs are easier to isolate and fix. A problem with naming sanitization is guaranteed to be in utils/naming.py and not buried within a 600-line __init__.py file.
• Scalability: Adding new features is now much cleaner. For example, adding a new "Arrange in Grid" operator is as simple as creating a new op_arrange.py file in the operators folder and registering it, without bloating the main __init__.py.
• Clear Separation of Concerns: The code now follows a standard design pattern where the UI (ui.py), core logic/actions (operators/), and helper functions (utils/) are all independent of each other.

Implementation Details

• The BF2M_OT_Prepare, BF2M_OT_Generate, and BF2M_OT_ExportMeshes classes were moved into their own respective files inside the new operators/ directory.
• The operators/__init__.py file was created to handle the registration of all operators within that module.
• The main __init__.py was updated to import the operators module and delegate the registration calls, simplifying its role to that of a central coordinator.
• The upcoming REPLACEMENT_MAP and sanitize_name function were moved into utils/naming.py.