Better MetaGraphs usage

In addition to #5:

- Do we really need `SchematicGraph` to hold `nodes` as a field, or can the nodes just be vertex metadata in `schematic_graph.graph`?
- Do we really need `ComponentNode`, or can we use `id` and `component` as our vertex metadata directly? That would be a bigger breaking change but also a big simplification. I originally liked the idea of having `ComponentNode` as an object the user could hold onto and pass around, which we use pretty extensively. The `ComponentNode` contains both the unique id (which is what the user would handle otherwise) and the non-unique component without having to go back to the graph with the id to get it.
- Can we use metagraph indexing properties or our own version of it with `node_dict` to index by node id, since we already guarantee unique ids? As in `schematic_graph["qu_1_1", :id]` returns that node? (Why is `node_dict` using `Symbol`, by the way?)

There might be more. The idea is that the closer `SchematicGraph` is to a literal `MetaGraph` the easier it is to get other things like the induced subgraph for free. Maybe serialization is another example. On the other hand we have some very real differences and I don't think we want to use a pure `MetaGraph`. For example, we can have nested schematic graphs, which we like to index into with `Tuple` indices.

I don't think we can switch to [MetaGraphsNext](https://juliagraphs.org/MetaGraphsNext.jl/stable/) as long as we want to allow arbitrary properties (since it needs to be type-stable).

Start by reviewing the SchematicGraph, ComponentNode, and node_dict entry points mentioned in the issue, then compare them with the desired MetaGraph behavior. Resolve whether nodes should be vertex metadata, whether ComponentNode should remain, and how id-based indexing should work; the issue is done when one design is chosen and its consequences for nested graphs, induced subgraphs, and serialization are documented.

Written by the indexing model from the issue text.