[Cashtab] Refactor Orderbook to handle more logic

Summary:
The current way that Agora loads offers is not ideal. We load and prepare all active listings on the network before we render anything.

It would be better if each OrderBook component accepted a tokenId instead of activeOffers. That way each OrderBook component could load its own activeOffers. When an offer is accepted or canceled, only one OrderBook needs to update (instead of the entire page).

This makes the component more robust and portable.

During this refactor, other improvements for simplicity and robustness were introduced, as it would have been much harder to complete this diff while leaving those complications around. It would be quite difficult to split these changes into several diffs, as we would have to preserve and work around some bad practices.

The extensive integration tests on the component allow this kind of complex but performance-improving refactor.

Summary of benefits

• Better conditional rendering of components that depend on calculated or API-fetched information
• We do not reload ALL offers after a buy or a cancel, only the orderbook affected
• Since each orderbook now handles the offer fetching and updating logic, it's much easier to stick an orderbook on another screen (for example a token landing page that only loads an orderbook for one token)
• Faster load time as we render an orderbook as soon as we get the tokenId, and then each orderbook (in parallel) starts getting its own offers

Test Plan:
npm test

This version is live at https://cashtab-local-dev.netlify.app/

Reviewers: #bitcoin_abc, emack

Reviewed By: #bitcoin_abc, emack

Subscribers: emack

Differential Revision: https://reviews.bitcoinabc.org/D17017