Evaluate the use cases for `ember-get-config`

[scalvert]

We should evaluate under what circumstances we need to use ember-get-config. Ideally, users can just adapt the code to do what they want using primitives this addon exposes.

[rwjblue]

I'd prefer to change this to an explicit setAxeOptions API instead. Folks can invoke that from their tests/test-helper.js and provide the default configuration that they want, or invoke it from a specific test to set custom override values. This would replace the _setConfigName method here:

ember-a11y-testing/addon-test-support/audit.ts

Lines 26 to 28 in cd1a8a6

	export function _setConfigName(configName = 'ember-a11y-testing') {
	_configName = configName;
	}

And it's usage here:

ember-a11y-testing/addon-test-support/audit.ts

Lines 112 to 114 in cd1a8a6

	if (typeof options !== 'object') {
	options = config[_configName]?.componentOptions?.axeOptions || {};
	}

This would allow us to remove the usage of ember-get-config and make things much more declarative (where you care about them)...

[drewlee]

Do we want to remove the configurations that are set in config/environment.js entirely or just the dependence on ember-get-config? Unfortunately, most of those options are leveraged by the "visual audit" feature of the component. I agree that it makes sense to set up axe options on the test side of things, but then consumers would need to define these in two different places. I think the long term means of handling this would be to extract the visual audit feature to a separate addon. But, in the short term, we should do this in a way that's backward compatible.

[scalvert]

We removed this functionality in #205.