Future of the `Symbol` object

In #144 I'm removing a ton of old C++ code for supporting Python 2, but also trying to modernize the use of the Python C API. The biggest change is switching from factory functions to real Python classes (where you can use type on them and subclass things). The biggest oddity in this work is that the Symbol "class" is not really a class. I've never had to dive deep into aggdraw to get a fully understanding so this is the first I'm realizing what a Symbol is...a Path.

The Symbol class is just a function that returns a Path. Specifically it is a conversion of SVG path specifiers to an AGG Path. This has been talked about in #49 a bit (CC @a-hurt @dov), but was mostly about extending SVG support through AGG extensions (written by @dov). All Symbol functionality comes down to a single usage in Draw.symbol which just does symbol->path to get the underlying AGG path storage and pass it to AGG. There is no real need for Symbol to exist in the current functionality. The discussion in #49 does not suggest extending it at all (at this time) to support anything and instead just uses Path.

So I see a couple options for how to clean this up and most can be mixed and matched:

1. Remove the Symbol class.
2. Make Symbol a subclass of Path
3. Make Symbol an alias for a new Path.from_svg classmethod that creates a Path

I like the idea of the classmethod and right now I don't think Symbol needs to exist, but a deprecation cycle would be nice so having a Symbol class that is a subclass of Path would be a nice way of doing that while accepting input from any users using Symbol now.

Thoughts?