Create generic container for relationships

[ml-evs]

Currently our "relationships" are hardcoded by storing lists like "file_objectIds" within each document that is the intended place to link items in the database.

Instead, we should encapsulate this in generic relationships objects that can have descriptions and types.

Initially these can be stored at the document level (and a choice can be made on a type-basis whether it is worth storing bidirectional links).

In the future, as suggested by @jdbocarsly, it is probably worth adding a new relationships collection that simply stores the IDs and link types for automatic bidirectional search (3NF style). At that point, we would need to decide whether the values of the relationships should be inlined into the document when returned from the API (i.e., an aggregation pipeline), to keep the current behaviour.

I will use this issue to track progress generally on the work started in #218:

• Add generic typed relationships container
• Make utility functions to create, remove, and manage relationships and keep them in sync with the rest of an item's data.
• Migrate all previous relationships to said container
  • Items <-> Items (i.e., Samples <-> Starting Materials)
  • Items -> Files
  • Items -> Blocks
• Consider storing relationships in separate database

[ml-evs]

#862 (comment)