Capture class hierarchies

- Alluded to by reviewer #2: (desirable feature for the MetaKB and maybe for DGIdb as well)

> A large proportion of normalization failures were due to a therapeutic class being referred to. The authors fear “unintended downstream effects” of capturing broader descriptors, but I would challenge this assertion. While the goal of normalization is to get a specific, unique entity, there would be value in capturing the parent-child relationship. For example, if TheraPy was used to power a clinical decision support tool that checks for drug-drug interactions, it could be programmed to identify concurrent use of multiple anticoagulant medications rather than having to be manually programmed for every possible combination. It could also be useful is a user wishes to know all drugs of a particular class.

Broadly, we'd like to support basic logical operations, like "is this drug a member of this class?". A naive way to do this would be to capture all parent classes, flatten them down to a single drug category layer, and then treat them kind of like a reference type. This would probably be pretty ugly in DynamoDB, though.

Anyway, not something we'll accomplish in the short term, but could dovetail well with the U grant proposal.

@mcannon068nw

Start by reviewing the existing therapy normalization model and how hierarchical data is represented in DynamoDB, then compare the needs of MetaKB and DGIdb. The issue does not name files, tests, or an entry point; done would require an agreed design for parent-child classes and queries that determine whether a normalized drug belongs to a normalized class.

Written by the indexing model from the issue text.