Don't use single global app lock resource

Currently we use a single app lock resource for an entire DB - `_az_func_Trigger`. This is ok for small apps that don't have scaling, but if you have a number of functions on the same database and those start being scaled out we can quickly start hitting timeouts since every transaction is processed serially by use of this lock.

The lock is still needed to prevent deadlocks, but it should be able to be scoped down to at least the table + function ID level (like we do for the leases tables) since each function should only be querying rows that are associated with that specific table + function from the global state tables (where the shared state is)

Care will need to be made to ensure that we don't scope it down too much though - for example if it's table + function ID but we have multiple functions all watching the same table then we should still ensure that they won't deadlock on themselves.

Start by tracing uses of the `_az_func_Trigger` app-lock resource and comparing them with the lease-table locking approach described in the issue. Done means concurrent functions on one database no longer serialize unnecessarily, while functions sharing a table cannot deadlock; verify this with scaled-out and same-table concurrency tests.

Written by the indexing model from the issue text.