Apply transactional AST transformation to accessor methods in non-domain classes

[jpdev01]

Currently, methods whose names start with get* or set* are explicitly excluded
from transactional method decoration by AbstractMethodDecoratingTransformation.

While this behavior makes sense for stateful objects such as GORM domain classes
(where getters/setters may trigger lazy-loading, hydration, or expected exceptions),
it can lead to surprising behavior in stateless or prototype-scoped beans, especially
Services and background jobs.

In these cases, annotating a method like setAsDeleted() or getOrCreate() with
@Transactional silently results in the method not participating in a transaction,
which may cause data to be flushed and persisted even when an exception is thrown.

This behavior is non-obvious and has been reported as a gotcha by multiple users
(see #14539).

Proposed change

Introduce an opt-in mechanism to allow accessor-style methods (get* / set*)
to be wrapped in transactional logic when explicitly requested.

This preserves the existing default behavior (no transactional decoration for
accessors), while allowing advanced use cases—such as stateless services,
batch jobs, and background processes—to opt in safely.

---

Rationale

The original exclusion of getters and setters is reasonable for domain classes
and other stateful objects, where invoking accessors inside a transaction can
lead to unexpected side effects.

However, in stateless service-style beans, accessor-prefixed methods are often
used as semantic operations rather than property accessors, and excluding them
from transactional decoration can result in silent and hard-to-debug data
consistency issues.

Making this behavior opt-in avoids breaking existing assumptions while giving
developers an explicit and predictable escape hatch.

---

Related discussions

• @Transactional not applied to setter-like service method #14539
• https://grails.slack.com/archives/C07M0GTDE/p1765557083792879

[jpdev01]

Backwards compatibility:
A potential approach would be to make this behavior opt-in to avoid impacting existing applications.
This is intentionally left open for discussion.