NickAkhmetov/HMP-180 Cell types landing page first pass

[NickAkhmetov]

This PR begins the implementation of the cell types landing page; this mainly only covers display-related aspects, and relies on some pretty loud usage of the cells/ontology API's since most of the table data can only be fetched for one term at a time.

It seemed like a logical pause point to open the PR here to identify any issues before implementing the more complex features

• Added routes_cell_types.py for cell-types related endpoints
  • /cell-types/list.json -> list of cell names provided by cells api
  • /cell-types/<cell_type>/description.json, /cell-types/<cell_type>/organs.json, /cell-types/<cell_type>/datasets.json look up the respective information for a single cell type
    • This is inefficient but we don't have an "aggregate" endpoint available to fetch this information for multiple cell types at a time.
    • I am working on crafting SPARQL queries to see if I can extract this information more efficiently, but this enhancement can be made in a future PR.
  • /cell-types/<cell_type>/assays.json is a placeholder for the "data types" lookup
    • Assays don't appear to be available in the cells API
• Added organs section grid and search bar
  • Have not added search related logic/filters yet
• Added table of cell types
  • While cell types are loading, table displays 10 rows of skeleton data
  • When cell types are loaded, table displays all rows of cell types and lazy loads individual columns (description/organ/assays placeholder)
  • When view datasets button is clicked, dialog pops up with list of dataset UUIDs that link to the appropriate browse/dataset/${uuid} link
    • cells API only provides the UUID's and azimuth information, no titles - we will need to build on additional functionality to get more relevant metadata for each dataset

Misc fixes:

• ResultsTable now has one tbody per table instead of one for each row
• fixed recurring provtable imports comment that was popping up in every PR as an automatic comment

Full page screenshot:

[NickAkhmetov]

Closing in favor of #3246 given how stale this implementation is.