Support loading from .glyphspackage

[anthrotype]

Fixes #435

Initially this is just adding the test .glyphspackage files ("saved as" from the existing .glyphs test files using the latest Glyphs.app), so the test is going to fail. Will follow up with the implementation itself.

[anthrotype]

So I added a load_package method to glyphs-reader's Font, and also changed the default Font::load to call load_package when the input path is a directory instead of a regular file. In the method I glue all the glyph plists together in the right order before constructing the RawFont from the combined plist and everything seems to work.
This was the easiest way to implement this; alternatively we could have define a new GlyphsPackageIrSource alongside the current GlyphsIrSource which is backed by multiple files instead of a single in-memory plist, but I think that would touch a lot more code. Personally I'm inclined to have it like this for now and refine later if need be.

[anthrotype]

(in case you were in the middle of a review, I just rebased on origin/main to incorporate #446 just merged, no other changes)

[cmyr]

Happy to see that this patch is not actually 3k lines of code. That said I think github is starting to choke on font.rs here and we should maybe split it up a bit?

A bunch of notes inline; I spent a while playing around trying to clean this code up a bit and it's not that easy, although it did motivate me to open #450, which should let us improve the situation somewhat...

[cmyr]

is this based on other code, or brand new?

[anthrotype]

if a glyph is named "infinity", "inf" or "nan" and the name is un-quoted (as Glyphs.app does when a string only contains ascii), our plist parser misunderstands it as a float
https://doc.rust-lang.org/std/primitive.f64.html#grammar
so I uses regex to add the quotes and make sure they stay as strings

We had code (that I removed here) which would fix up the parsed glyph plist dict and unconditionally replace "glyphname" typed float with a hard-coded "infinity" string (ignoring "inf" or "nan").

I think the python openstep-plist parser (used by glyphsLib and thus fontmake) does not have this problem because it can detect that an unquoted string is neither an integer nor a float (https://github.com/fonttools/openstep-plist/blob/c9acd408ba3a374ba41dd62f595f43fa2e5bfa6f/src/openstep_plist/parser.pyx#L267-L309) and thus treat it as string; I think our current rust plist parser attempts to parse as number and if that succeeds (as in the case of "infinity") it treats it as such, so we need to prevent that -- or change the parser (but I haven't even looked into that.. would you like me to?)

[anthrotype]

I changed the plist parser itself to always treat "infinity", "inf" and "nan" as strings, so we don't need the regex hack any more. I don't think inf or NaN are useful in font source formats

[cmyr]

if you rebase on #450 I hope you can now just write,

Suggested change

	let glyph_plist = Plist::parse(&glyph_data)
	.map_err(|e| Error::ParseError(entry.path(), format!("{e:#?}")))?;
	let Plist::Dictionary(ref glyph_dict) = glyph_plist else {
	return Err(Error::ParseError(
	entry.path(),
	"Glyph must be a dict".to_string(),
	));
	};
	let glyph_name = glyph_dict
	.get("glyphname")
	.map(|s| s.to_string())
	.ok_or_else(|| {
	Error::ParseError(
	entry.path(),
	"Glyph dict must have a 'glyphname' key".to_string(),
	)
	})?;
	let glyph_dict = Plist::parse(&glyph_data)
	.and_then(Plist::expect_dict)
	.map_err(|e| Error::ParseError(entry.path(), e.to_string()))?;
	let glyph_name = glyph_dict
	.get("glyphname")
	.map(|s| s.expect_string().ok())
	.ok_or_else(|| {
	Error::ParseError(
	entry.path(),
	"Glyph dict must have a 'glyphname' key".to_string(),
	)
	})?;

which... is still pretty gross!

[cmyr]

There's definitely a lot of room for cleanup here but I think it's worth getting this merged :)