Reduce and document usage of `exports`

[tedinski]

After a chat with Patrick @200sc today, I realized we may be over-using the exports declaration.

Partly I think this was caused by melt-umn/copper#15 which demanded that concrete syntax get broken up into subgrammars, which is not a desirable design. We should make sure our examples are fixed now.

But right now, we have this as part of this standard skeleton:

https://github.com/melt-umn/ableC-skeleton/blob/master/grammars/edu.umn.cs.melt.exts.ableC.skeleton/Export.sv

This encourages the use of exports.

This file exists, I believe, for two reasons:

1. We want to make it not possible to construct erroneous parsers, by automatically including dependent grammars because this file exports them. (i.e. when extensions extend extensions, you can't "leave out" the one in the middle because it gets magically added back in by an export relationship.)
2. Convenience: just import the extension (or name it in a parser), without having to say :abstractsyntax or :concretesyntax.

IMO, ideally, we'd do away with this file, and not use exports by default at all. I think if we get melt-umn/silver#20 fixed, then the problem of leaving out grammars from a parser will no longer be a catastrophically confusing one. And the convenience doesn't seem worth it to me.

I think exposing new users to the exports concept can be especially confusing (especially since I think the only language that works similarly is Haskell, and I think it might even work slightly differently there, too...) The added burden of having to add :concretesyntax to grammars in parser declarations when telling our user story for composing extensions is minor. (And long term, we want "aspect parser" anyway to make that easy peasy.)

---

If we don't wish to do the above, then I think we need very, very good documentation of what's going on here and why. This file should not be devoid of comments.

cc @krame505 @ericvanwyk @TravisCarlson for discussion?

[krame505]

To me, it seems that the biggest reason to export the concretesyntax is for convenience to end users. After all, putting all the concrete syntax in a top-level concretesyntax grammar within the extension is just a convention, which could be changed in a more complex case, such as an extension that involves options.
Furthermore, if we do end up implementing some sort of 'extension package manager' such as what Nathan has proposed, needing to automatically figure out what sub-grammars to actually include in the parser spec by default would be a challenge, and relying on there always being a grammar named concretesyntax seems rather inflexable.
I am in favor of exporting the 'abstractsyntax' grammar as well, for the purpose of symmetry - importing the top-level grammar and getting the concrete syntax but not the abstract syntax would be an unexpected and potentially confusing behavior to someone attempting to extend an existing extension.
I do agree that more documentation is needed on this - I will try to do so when I get a chance.