Add generic form-field editing support

This issue tracks the next editor-level step for form fields in pdf-elements.

The goal is to add generic form-field editing behavior after the public field/widget model is defined.

This issue is blocked by #84. The implementation details and final scope must follow the data model, naming and compatibility decisions made there.

Expected direction

After #84 is completed, this issue should provide the common editor behavior needed by future field types, such as:

• create and place a field widget;
• select a field or widget;
• move and resize widgets;
• edit shared field properties;
• edit widget-specific properties;
• support values, required/read-only state and options where applicable;
• keep one logical field connected to one or more widgets;
• expose behavior through the public API without depending on internal Vue state.

The implementation should remain generic to a Vue 3 PDF editor and must not introduce LibreSign or Nextcloud workflow concepts.

Out of scope

Do not use this issue to implement every field type.

Specific behavior for text fields, checkboxes, radio groups, dropdowns and other controls should be added only after the generic editing foundation is stable.

PDF AcroForm parsing, PDF writing and signing are also outside the scope of this package.

Acceptance criteria

The final acceptance criteria should be refined after #84 is completed.

At minimum, the implementation should:

• follow the public field/widget model defined in #84;
• provide common editing behavior that can be reused by different field types;
• support multiple widgets for the same logical field;
• keep field-level and widget-level properties clearly separated;
• remain compatible with generic non-form overlay use cases;
• include unit and browser-level tests for the shared behavior;
• avoid LibreSign- or Nextcloud-specific domain concepts.

Dependency

Blocked by #84.

Do not start implementation until the model and public API decisions from #84 are available.

Additional context

• If you have questions, feel free to ask in this issue.
• Give a ⭐️ to pdf-elements if you find the package useful.
• You can also support the project by giving a ⭐️ to LibreSign.

Wait for issue #84, then start by reading its public field/widget model, naming, and compatibility decisions. Use those decisions to define the shared editor behavior and public API, with unit and browser-level tests covering multiple widgets, separated field and widget properties, and generic overlays. Done means the foundation is reusable without implementing individual field types or PDF/signing workflows.