Migrate the recipes/plugins to an external repository

[justinGilmer]

Describe the behavior you would like added to mBuild The recipes we currently have contained within mBuild like Polymer, Alkane, TiledCompound etc. are treated like external recipes by plugging into the mbuild.plugins entry_point. These should be migrated out to a separate repository that could then be a default requirement.

Describe the solution you'd like Remove mbuild.lib.recipes to an external repository named mbuild_extras or something like this.

Describe alternatives you've considered N/A

Additional context This could be a default requirement, but also not necessary since it is not a core feature.

[mattwthompson]

I disagree - I like the idea of some basic recipes being shipped internally. Making a separate recipe repo/package for each of these smaller recipes seems like a overhead for minimal value to me.

[b-butler]

I think that have this in a separate package is a good idea. I don't think there is a problem in by default installing the mbuild_base_recipes repo or whatever it would be called. I could also see the case for it being not installed by default. However, I think this approach in general has multiple benefits.

1. Clear delineation of core logic with use of that logic
2. Gives a good (and managed by mos-def) example repository for writing recipes.
3. With issues like #704, #705 I believe that this is a natural extension.

[chrisiacovella]

I can see how moving recipes like "alkane" to a different repo would be good, but I agree with @mattwthompson that some basic recipes should be included, especially the more generic recipes like polymer, tiled_compound, etc. Quite a number of our specific recipes (used in actual research) use the polymer and tiled_compound classes almost as "core" components.

[mattwthompson]

I am open to mbuild_base_recipes if it's a lightweight package and we agree to a deprecation schedule - since, as @chrisiacovella points out, we import them fairly often