Proposal: remove object-oriented definition APIs from public Dagster API

[mgasner]

This would entail removing SolidDefinition in favor of @solid, PipelineDefinition and DependencyDefinition in favor of @pipeline, ResourceDefinition in favor of @resource, LoggerDefinition in favor of @logger, RepositoryDefinition in favor of @repository, and ScheduleDefinition in favor of @schedule. The goal here is to reduce the user-facing API documentation/tutorial surface & to avoid presenting what is in effect a false choice (since the decorator APIs are equally powerful and to be preferred in every case of which we're aware).

We would deprecate in 0.10.0 and remove in 0.11.0.

[schrockn]

These are still important for folks who build frameworks over Dagster, e.g. a user who has built their own DSL for building dependency graphs.

[mgasner]

This makes sense. Some ideas:

• Surface the documentation separately from the public API on docs.dagster.io
• Namespace them somewhere else (under dagster.internals or dagster.definitions) -- this would break backcompat but with a pretty straightforward migration
• Reconsider this as part of a 1.0 release

[schrockn]

I think surfacing the documentation separately is logical. Moving them around in a breaking fashion seems unnecessary to me for now. Thrashy without that much upside.

[schrockn]

We could do work to de-emphasize them and cast them as "advanced" APIs, but we need to maintain backwards compatibility.