Investigate uncommitted changes + table rename

[snaury]

We store table's path id in LockRanges, but it doesn't seem to be ever updated when renaming tables. This makes me wonder what would happen when table is renamed while it has persistent uncommitted changes active (and when tx tries to commit those changes), especially when tablet is then restarted. Need to investigate, there may be a bug.

[snaury]

Found some problems:

1. Trying to commit a transaction after renaming a table fails, but uncommitted changes are not rolled back (presumably they would rollback after a restart when lock is restored, but I haven't checked that yet). We should rollback changes more explicitly (transaction that crosses a rename boundary must not be able to commit).
2. Trying to commit a transaction after a restart causes a check:

2024-05-28T12:25:02.951235Z node 1 :TX_DATASHARD TRACE: KqpCommitLock LockId: 281474976715659 DataShard: 72075186224037888 Generation: 1 Counter: 0 SchemeShard: 72057594046644480 PathId: 2 HasWrites: true
VERIFY failed (2024-05-28T12:25:02.951246Z): Unexpected failure to find table [72057594046644480:2:0] in datashard 72075186224037888
  ydb/core/tx/datashard/datashard_user_db.cpp:306
  CommitChanges(): requirement localTid failed

That happens because the persistent lock is restored on restart, and we apparently don't validate transaction body enough and don't detect an attempt to commit with a changed schema here. Lock has a table id, but that table no longer exists, so it crashes trying to commit.

We need to detect that persistent lock is no longer valid and clean it up asynchronously. It certainly shouldn't be possible to either validate or commit that lock after rename.