Add SynchronizedBehavior with non-reentrant lock

[kzu]

Fixes #271.

SynchronizedBehavior Design

Summary

Adds SynchronizedBehavior, an IStuntBehavior that serializes overlapping calls on a stunt using a standard object lock (normal lock statement semantics, reentrant).

This follows the normal pattern used by Castle DynamicProxy interceptors and .NET in general: lock (syncRoot) { next(); }. No custom lock types, no shared tables.

API

public class SynchronizedBehavior : IStuntBehavior, ICloneable
{
    public SynchronizedBehavior(object? syncRoot = null);
    public bool AppliesTo(IMethodInvocation invocation); // true for all
    public IMethodReturn Execute(IMethodInvocation invocation, ExecuteHandler next);
    public object Clone();
}

• syncRoot: optional lock object. Default is a private object owned by the behavior, so one behavior locks one stunt. Passing an explicit object lets multiple behaviors coordinate on the same lock (standard lock semantics).
• Implements ICloneable so BehaviorPipeline.Materialize gives each stunt its own lock by default; an explicit lock object stays shared across clones.

Behavior

flowchart TD
    A[Execute] --> B[lock syncRoot]
    B --> C[next invocation]
    C --> D[return IMethodReturn]

Loading

Simple: acquire the lock, invoke next, release. Reentrant (same thread can re-enter, like Monitor).

Acceptance tests (scenarios)

• Two overlapping calls run one at a time (barrier + counter).
• Re-entrant call on same thread succeeds (reentrant lock, no deadlock).
• Explicit shared lock coordinates two stunts; default does not.

Files

• src/Stunts/SynchronizedBehavior.cs (new)
• src/Stunts.UnitTests/Scenarios/Synchronized.cs (new)

Notes

Deviates from the original issue text (which specified non-reentrant): per discussion, we follow the normal .NET/Castle lock semantics (reentrant Monitor).