Consolidate aesthetic information

[thomasp85]

This PR adds an aesthetic module which takes on the responsibility of handling aesthetic names etc. It creates a single source of truth throughout the code base and importantly remove a whole range of hardcoded matching for positional aesthetics

[teunbrand]

A few nitpicks but this LGTM.
Something beyond this PR is whether we should automate writing the aesthetic_name grammar component based on these definitions. See

ggsql/tree-sitter-ggsql/grammar.js

Lines 640 to 651 in 3b6b659

	aesthetic_name: $ => choice(
	// Position aesthetics
	'x', 'y', 'xmin', 'xmax', 'ymin', 'ymax', 'xend', 'yend',
	// Aggregation aesthetic (for bar charts)
	'weight',
	// Color aesthetics
	'color', 'colour', 'fill', 'stroke', 'opacity',
	// Size and shape
	'size', 'shape', 'linetype', 'linewidth', 'width', 'height',
	// Text aesthetics
	'label', 'family', 'fontface', 'hjust', 'vjust'
	),

.

[teunbrand]

Another thought that occurs to me: what if this was implemented as a struct? Like one Aesthetics struct containing different fields like positional with aesthetic names and methods like is_primary_position() etc. We'd don't have to faff with importing the precise checkers and whatnot because they'd be encapsulated. I'm not saying this is necessarily a better design decision, but might be worth giving a small think.