Generalize Group-By glossary processing.

[dgou]

Follow on to PR #56

Place to have discussion for how the new group-by-step-name functionality can be generalized so that things aren't hard coded in so many places.

[dgou]

@mrkaiser I opened this as a draft as a better place to have the discussion about how to generalize the glossary processing.

[dgou]

Early morning Saturday pre-coffee brain dribblings...

So my thoughts on this are that the glossary processing is kind of messy right now with parts of it in writer.py and parts in glossary.py And if we would add another glossary option (such as being able to group by "interesting" words in the step definition, such as, say, could be configured, so I could see all the "login" related steps together regardless of the step type), we'd have to keep more glossary dicts to update in writer and then more in glossary. That is to say, the way the code evolved, knowledge about the glossary organizational mechanism leaked out. My thought is to add another class to glossary.py to handle that logic, so that writer.py doesn't have to know how the glossary is being constructed (and also so it doesn't build glossaries that we aren't actually going to use).

To paint a picture in words:

1. have classes in glossary.py that would encapsulate the logic of how to add a step to themselves. This would encapsulate what is now the logic in writer.py for adding steps.
2. based on the command line parameters the desired glossary class would be instantiated and passed to whatever functions care about the glossary - this would replace the exported globals from glossary.py
3. Having '1' means we can even define a glossary class that would permit multiple glossary types to be emited in the same build, so I could have both the 'group by steps' and a 'group by concept' if I wanted to, simply by defining a new class that would contain both of those and forward to them both.