Adds util functions needed for dynamic prepocessing pipelines

[angela97lin]

Closes #843

Q's:

• We could do a lot more checks, such as checking target values and determining which pipeline to generate automatically, or at the very least, having some sort of check that everything makes sense. Yet this seems to mirror our checks elsewhere, should we do it here too?

[codecov]

Codecov Report

Merging #852 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           master     #852    +/-   ##
========================================
  Coverage   99.70%   99.70%            
========================================
  Files         195      195            
  Lines        8000     8181   +181     
========================================
+ Hits         7976     8157   +181     
  Misses         24       24            

Impacted Files	Coverage Δ
evalml/pipelines/__init__.py	100.00% <ø> (ø)
evalml/pipelines/utils.py	100.00% <100.00%> (ø)
evalml/tests/component_tests/test_components.py	100.00% <100.00%> (ø)
evalml/tests/pipeline_tests/test_pipelines.py	99.80% <100.00%> (+0.05%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d220dca...e306216. Read the comment docs.

[dsherry]

This is exciting! 🎊 great stuff. Left some suggestions and docs tweaks, but nothing blocking merge IMO!

We should resolve the convo about adding problem_type to get_preprocessing_pipeline sometime soon though (before the release).

Ideas for more unit test coverage:

• Check input and output dtypes--does make_pipeline work with np.array as input? pd.DataFrame with no column names?
• Validate that we throw if the provided estimator isn't an Estimator subclass -- I think you already have this

That's all I could think of right now!

Food for thought for the future: we will likely end up supporting different versions of the preprocessing functions. Some may even be in external modules. We don't need to worry about this in this PR, but we should consider: what could we do to make backwards compatibility easy? One idea: add a "preprocessing_version" string input, which we could use to map to the impl. Another idea: keeping get_preprocessing_pipeline private could help us have more flexibility.

[kmax12]

looks solid to me

[kmax12]

Another idea: keeping get_preprocessing_pipeline private could help us have more flexibility.

I agree with @dsherry here. we can make this public later if we chooce. especially since we have make_pipeline(X, y, estimator, problem_type), which is cool to expose

[kmax12]

LGTM

[dsherry]

@angela97lin thanks for re-requesting. I left a comment in response on all_estimators. Once that's resolved LGTM