Rationalize the use of custom builds in AzureML environments (sdk2.0 ready?)

[jfomhover]

To run multiple "builds" of components such as lightgbm inferencing or lightgbm training, we currently use dockerfiles that we substitute to the default component dockerfile at build time.

This approach has pros/cons.

pros:

• dockerfiles are easy to build and test in a build
• dockerfiles are clean cut dependencies that everybody can read
  cons:
• substituting docker builds at component run time is a hacky solution
• we don't support substituting both docker+conda
• it can introduce unexpected behaviors when component has conda env and we inject a docker (component will use custom docker, but still build conda on top of it)

We should think about using clean environments specifications instead, with docker and/or conda as part of an AzureML environment specification. When running custom builds, we substitute the entire component environment and not just the build.