Idea: Refactor some internals to reduce complexity

[beryllium]

It can be quite difficult to understand how all the pieces of Sculpin fit together - in fact, it seems a bit more difficult than is necessary for what the tool does. This is partly because it's based on earlier versions of Symfony, partly because it used to be oriented around being a phar (with embedded composer), and partly because some of the internals are just ... tangled.

When starting on a refactor of this, it would be a good idea to add some new functional test cases to ensure that some currently untested real-world usages of Sculpin are handled as expected - this would help to prevent surprises. Things like bundles/plugins, themes, etc.

[dbu]

one offender seems to me how converters are registered for the sources. we have https://github.com/sculpin/sculpin/blob/cb82b08f77a951c06d4c9ceb3dba0c7c2d1baee2/src/Sculpin/Bundle/SculpinBundle/DependencyInjection/Compiler/CustomMimeTypesRepositoryPass.php which in the end sets the parameter that is used by the converter itself:

sculpin/src/Sculpin/Bundle/MarkdownBundle/MarkdownConverter.php

Lines 84 to 95 in cb82b08

	public function beforeRun(SourceSetEvent $sourceSetEvent): void
	{
	/** @var SourceInterface $source */
	foreach ($sourceSetEvent->updatedSources() as $source) {
	foreach ($this->extensions as $extension) {
	if (fnmatch("*.{$extension}", $source->filename())) {
	$source->data()->append('converters', SculpinMarkdownBundle::CONVERTER_NAME);
	break;
	}
	}
	}
	}

or am i missing something? to me it looks like we would end up with the same functionality if we would directly define the extensions in the service definition for the converter. there seems to be no further concept of mime type that leads to the converter automatically being used. or did i overlook something?