`before_replace` triggers inconsistency when updating a primary key

Tarantool version: 2.11.0-entrypoint-358-g9965e3fe4 (current master at the time of writing)

I've noticed some strange behaviour with our before_replace triggers:

1. A usual insert of a duplicate key to a unique index leads to an ER_TUPLE_FOUND error. However, when the space has a before_replace trigger, the same insert completes just fine:

tarantool> box.cfg{}
---
...

tarantool> box.once('bootstrap', function()
         > box.schema.space.create('test')
         > box.space.test:create_index('pk')
         > end)
---
...

tarantool> box.space.test:insert{1}
---
- [1]
...

tarantool> box.space.test:insert{1} -- duplicate 
---
- error: Duplicate key exists in unique index "pk" in space "test" with old tuple
    - [1] and new tuple - [1]
...

tarantool> box.space.test:before_replace(function(old, new) return new:update{{'=', 1, new[1]}} end)
---
- 'function: 0x0111209ec0'
...

tarantool> box.space.test:insert{1} -- same duplicate, but succeeds with a no-op before_replace trigger!
---
- [1]
...

2. Usually it's not allowed to change tuple's fields indexed by primary key in before_replace triggers. But when inserting a tuple not present in space this works just fine, and also allows duplicates like in example 1:

tarantool> box.cfg{}
---
...

tarantool> box.once('bootstrap', function()
         > box.schema.space.create('test')
         > box.space.test:create_index('pk')
         > end)
---
...

tarantool> box.space.test:insert{1}
---
- [1]
...

tarantool> box.space.test:select({}, {fullscan=true})
---
- - [1]
...

tarantool> box.space.test:before_replace(function(old, new) return new:update{{'=', 1, 2}} end)
---
- 'function: 0x0110d1da30'
...

tarantool> box.space.test:insert{1} -- error as expected
---
- error: Attempt to modify a tuple field which is part of primary index in space 'test'
...

tarantool> box.space.test:insert{3} -- no error for a new tuple!
---
- [2]
...

tarantool> box.space.test:insert{4} -- and even duplicates!
---
- [2]
...

So, first of all, seems like duplicate keys should be checked after before_replace triggers are executed, not earlier.
And, secondly, we should either disallow updating fields indexed by primary key completely or allow such updates and handle them correctly in all cases.

Start by running the Lua reproductions in the issue for duplicate inserts and primary-key changes inside before_replace triggers. Trace the space insertion and trigger path to determine when uniqueness and primary-index checks occur. Done means the trigger behavior is consistent for existing and new tuples, with regression coverage for the reported cases.