fixes #101 #115

The idea is to add a new ResvgBuilder type, which does all the pre-resvg resolving stuff. Behind the scene it uses the xml reader which resvg uses and find all text nodes, try to gather font information of them (by using a naive ancestor-inheritance logic) and output all fonts needed via a new api texts_to_resolve().

Users could use this new api to get whatever font they have which satisfies the given font key, and call resolve_font(buffer) to feed the font buffer to the builder.

Later on, builder will uses these fonts to construct the font_db::Database instance so that the texts will not be eliminated by resvg/usvg.

Some drawbacks:

• This font attributes tracking logic is not perfect, e.g. CSS will not be parsed. Even though the logic in usvg is also not perfect, the impl in this PR is worse.
• Using fonts that don't meet the query is not supported. E.g. if the SVG wants monospace and you want to render it by providing a ubuntu mono font, it would just fail.