Generalize handling interaction between feature selectors and categorical features

In #3419 we added a fix to handle Email and URL features in default algorithm of such features by backtracking and looking at not only the feature provenance `EmailFeaturizer` and `URLFeaturizer` but also the feature provenance from `OneHotEncoder` for feature selection. This is because `EmailFeaturizer` and `URLFeaturizer` both generates categorical features that in turn get encoded by the `OneHotEncoder`. The flow is as follows:

`url` ---URLFeaturizer--> `URL_TO_DOMAIN(url)`----`OneHotEncoder`---->`URL_TO_DOMAIN(url)_alteryx.com`

#3419 introduces a fix specifically for Email and URL features but this exact issue could pop up again if another logical type is introduced that EvalML generates categorical features from.

Acceptance Criteria:
- generalize solution in #3419 to apply to future logical types where EvalML will create a categorical feature from

------------------------------------------------
"I think this is good but I feel like we need something more general here long term. If a new logical type is introduced, we might fall into the same bug again. Let's file an ice box issue to not forget. I can try to elaborate more there."

_Originally posted by @freddyaboulton in https://github.com/alteryx/evalml/pull/3419#discussion_r839739138_