Sync persistent RPC (v2) status updates & delete events Edge->Cloud

[MazurenkoNick]

Pull Request description

Closes #210

Problem

Persistent RPC (v2) state was maintained independently on the edge and the cloud. When a persistent RPC changed status or was deleted on the edge, the cloud never found out, leaving stale RPC copies out of sync between the two.

What this does

Propagates persistent-RPC (v2) lifecycle changes from the edge to the cloud by hooking the entity lifecycle (the same mechanism used for every other synced entity), so status transitions and deletions on the edge are mirrored on the cloud.

• Status updates (Edge → Cloud): TbRpcService.save now publishes a SaveEntityEvent. CloudEventSourcingListener turns it into a DEVICE/RPC_CALL uplink notification carrying {requestUUID, rpcStatus, response?}; the cloud locates the matching Rpc (same id == request UUID) and updates it, guarding against stale,
  out-of-order status uplinks regressing a terminal RPC.
• Delete (Edge → Cloud): TbRpcService.deleteRpc fetches-before-delete and publishes a DeleteEntityEvent, uplinked over the same DEVICE/RPC_CALL channel with rpcStatus = DELETED; the cloud removes its copy.
• Delete (Cloud → Edge), all statuses: RpcV2Controller.deleteRpc now routes through TbRpcService and pushes a DELETED marker to all related edges regardless of status (previously terminal RPCs were skipped); the edge's DeviceCloudProcessor removes the local copy and clears the pending actor entry for intermediate
  RPCs.

General checklist

• You have reviewed the guidelines document.
• Labels that classify your pull request have been added.
• The milestone is specified and corresponds to fix version.
• Description references specific issue.
• Description contains human-readable scope of changes.
• Description contains brief notes about what needs to be added to the documentation.
• No merge conflicts, commented blocks of code, code formatting issues.
• Changes are backward compatible or upgrade script is provided.
• Similar PR is opened for PE version to simplify merge. Crosslinks between PRs added. Required for internal contributors only.

Front-End feature checklist

• Screenshots with affected component(s) are added. The best option is to provide 2 screens: before and after changes;
• If you change the widget or other API, ensure it is backward-compatible or upgrade script is present.
• Ensure new API is documented here

Back-End feature checklist

• Added corresponding unit and/or integration test(s). Provide written explanation in the PR description if you have failed to add tests.
• If new dependency was added: the dependency tree is checked for conflicts.
• If new service was added: the service is marked with corresponding @TbCoreComponent, @TbRuleEngineComponent, @TbTransportComponent, etc.
• If new REST API was added: the RestClient.java was updated, issue for Python REST client is created.
• If new yml property was added: make sure a description is added (above or near the property).