Allow different text-domains per subdirectory

Is your feature request related to a problem?

In a site-level directory, there may be different directories of custom code - plugins and theme(s). It's not possible to set a text_domain property on the top-level .phpcs.xml.dist, since it wouldn't be correct for some of the directories.

For a single plugin or theme repo, one would do something like this:

<rule ref="WordPress.WP.I18n">
	<properties>
		<property name="text_domain" type="array">
			<!-- This value is the theme text domain. -->
			<element value="my-child-theme"/>
		</property>
	</properties>
</rule>

But that doesn't work for a site repo.

One workaround, is to add a PHPCS config file at the theme or plugin directory level, with the above, and <rule ref="../../.phpcs.xml.dist"/> so it runs all of the other desired checks, but that means having to cd into each directory which has it's own text domain, and run PHPCS. With clients (former and current) that have 20+ plugins, this isn't feasible without further scripting.

Describe the solution you'd like

I don't know if PHPCS exposes the full filepath such that its available to the WPCS Sniff.php, but if so, I'd like to see support for specifying the file path to which the text domain would apply. Something like this in the top-level .phpcs.xml.dist:

<rule ref="WordPress.WP.I18n">
	<properties>
		<property name="text_domain" type="array">
			<element key="themes/my-child-theme" value="my-child-theme"/>
			<element key="plugins/my-plugin" value="my-plugin"/>
			<element key="plugins/my-other-plugin" value="different-text-domain"/>
		</property>
	</properties>
</rule>

In WordPress.WP.I18n, if there was no key, it would run with the current behaviour. If there was a key, then it would check the relative file path against the key, and if that matched, use the value as the text domain.

Additional context (optional)

This "custom property value per file path match" could be generalised into something supported at the PHPCS-level, but that would be harder to implement to satisfy all potential use cases. Just addressing this at the WPCS level seems doable (if the file path is available to compare against).

Start by reading the WordPress.WP.I18n sniff and its Sniff.php implementation, then check whether PHPCS exposes the full file path there. Review the top-level .phpcs.xml.dist examples in the issue. Done means path-keyed text_domain values work for matching subdirectories while entries without a key retain current behavior.