Handle concurrency issues better in specify

[realVinayak]

A copy-paste of issue: https://github.com/specify/specify-development/issues/19

1. Workbench performs everything in a transaction. If this was alone by itself, this wouldn't have caused an issue.
2. Subtle concurrency issues with trees can issues. For instance, workbench if uploads trees, then it causes issues with tree actions which involve node numbering (because we end up doing a select * where nodenumber = whatever for update, but since node numbers aren't indexed, it implictly locks all rows (this is still not a full table lock)
3. If you make collection objects via the form, when workbench is uploading to collection objects, then autonumbering causes a write lock on collectionobject, collection, and other tables. This is very bad. form's lock is delayed by workbench, so form save doesn't happen (gets timed out). Plus, no body is able to use specify because a simple '/specify/' request causes a read request from collection table (which waits for the write request from collection from form to be granted)

See #5047.

Some raw ideas:

Make this accept two args: one for read and one for writes.

specify7/specifyweb/specify/lock_tables.py

Line 9 in dfe5887

def lock_tables(*tables):

Make this return 2 sets, one for read and one for writes. Repetition isn't allowed, so if a table is in both, elevate it to a write (just remove it from read). Put all the discipline, collection, and uniqueness rule tables, and the scope_table in the read set (basically, everything we know we won't write to)

specify7/specifyweb/specify/autonumbering.py

Line 52 in dfe5887

def get_tables_to_lock(collection, obj, field_names) -> Set[str]: