non-mutating entity callbacks

The spec has always said that callback listeners are allowed to mutate entity state, and this includes `@PreUpdate`, which is now been sorta re-characterized as representing an event associated with the database `UPDATE` operation, *not* the mutation of the entity itself.

I have run into a discomfort with this that for the end user probably isn't very significant but for me as an implementor feels quite unnatural.

The issue is that I can't really call `@PreUpdate` right before executing the SQL `UPDATE`, or `@PreInsert` right before executing the `INSERT`, because I have to know the final state of the entity earlier than that, to even know if I'm going to execute the `UPDATE` or `INSERT`. So right now these things need to happen during what we in Hibernate think of as the "pre-flush" phase of flushing, and not during execution of the "actions".

This isn't *terrible* but it's not really what I _felt_ these events were supposed to represent.

On way to recover the behavior I thought I was getting would be to allow a callback listener method to specify that it doesn't mutate the entity (that also allows a useful performance optimization). So, something like:

```java
@NonMutating @PreInsert
void beforeInsert(Book book) {
...
}
```

A `@NonMutating` listener could be called closer to the database operation.

I guess the question is: is this a sufficiently-general thing (and I know my description was kinda handwavey) or is it something very specific to our implementation?

No files or tests are named. Start by reading the callback behavior described in the issue, especially the timing of @PreUpdate and @PreInsert during pre-flush versus database action execution. Done would require a resolved, sufficiently general design for marking callbacks as non-mutating, including the proposed annotation and its lifecycle semantics.

Written by the indexing model from the issue text.