Ensure that ACSF module is not disabled via config

[lcatlett]

Recently the ACSF product team discovered that if the ACSF module is disable via config split in the middle of BLT site update and tasks, other downstream BLT tasks that use the site_name and other variables set early when bootstrapping Drupal in BLT's pre-sites-php hook are set to null. Since the drush cache config also uses this information to generate a unique directory name per-site, this can result in race conditoins and other erratic results when running blt drupal:upate on ACSF sites. There should be a better developer and user experience to prevent this from happening in both BLT and the ACSF module.

[mikemadison13]

FYI @lcatlett i noticed something on this with config split recently as well. We can certainly try to enable acsf module (as we are with config split) but if core.extensions does not have this module turned on, the second we do a config import, it's going to get turned back off again.

We likely need to add some explicit debugging statements that WILL get printed in the ACSF deploy errors so we know that it's happening because ACSF module is disabled. Not sure we can actually "force" it to be enabled though given the way config import works.

[mikemadison13]

#3369 provides additional guidance for the failure in 10.x. It may need to be back ported to 9.2.x.

[danepowell]

I agree that there's not an elegant way for BLT to enforce this, I think the best we can do is provide a helpful error as we do in #3369