Formally document thread safety

[Ravenslofty]

We have a bunch of implied threading constraints throughout nextpnr, and these are hindering performance scaling by requiring working around them through abstraction layers - router2 for example.

We can already group certain APIs as things we know are independent - the logging API and the pip/bel manipulation API are separate, but within them they are not thread-safe.

It would be useful to describe these within the architecture API docs; especially for performance-critical APIs like pip/bel manipulation, it would be useful if the API guaranteed that pips that are physically separate (are not connected by a wire) can be modified concurrently. (This would implicitly forbid dynamically allocated data structures that are not protected by a lock)