Reconsider scope of built-in serialization (io::to_dot)

Graaf is positioned as a lightweight, high-performance graph library, but it also ships \`io::to_dot\` -- a DOT/Graphviz string serializer. That's a different kind of concern from \"fast graph data structure + algorithms,\" and I've been going back and forth on whether it belongs in core long-term.

To be clear on the actual coupling: \`io/dot.h\` is already a separate, opt-in header -- \`graph.h\` doesn't include it, so anyone not using serialization doesn't pay for it today. This is more a question of scope/positioning than a technical problem.

Options worth weighing:
- Keep it as-is (opt-in header, no real cost to not using it).
- Move it to a separate package/repo, keeping Graaf itself narrowly focused on the data structure and algorithms.
- Something in between (e.g. keep it, but stop adding features to it).

No decision made yet -- opening this mainly to think out loud and leave a paper trail before it comes up again (e.g. #301). Feedback welcome.

The issue is about the architectural scope of the library, specifically the io::to_dot serializer in io/dot.h. First, understand how the library is structured by reading graph.h and io/dot.h. Review the discussion in issue #301 for context. The goal is to evaluate the coupling and propose a decision on whether to keep, move, or limit the serializer, not to implement a code change.

由索引模型根據 Issue 內容生成。