Allow for _{digit} in module names

[gaow]

This is currently disallowed because it conflicts with our internal convention and violation of it causes infinite loop in DAG. This can be relaxed, though, given some work (not hard but tedious). Please bump this if it is an urgent request. Otherwise I'll not fix it immediately but perhaps in a month time or so.

[gaow]

Okay to continue on the slack discussion let me be a bit clear on what are allowed and what are not, for module name and variable names.

Not allowed:

1. Any . anywhere in the module name, or parameter name, because it is not valid Python or SQL variable names.
2. _ as prefix. eg, _simulate, because R does not like it.
3. _ as suffix, eg. simulate_, because it looks incomplete and ugly.
4. - in variable name, because it will not work in most languages
5. _ followed by digit / digits as suffix, in module name, eg, simulate_1. This is because _1, an internal convention of index, will cause us troubles. The reason we pick _{digit(s)} as index is because it feels natural that way (eg, LaTeX). Also, since our automatic output file naming convention is with _{digits} it will create a minor issue there too.

Allowed:

1. simulate_V2 or simulate_2V for module names.
2. x_1, x_2 etc in variable names.

So the only restriction that we can possibly relax is _{digits} in module names.

[pcarbo]

@gaow It seems that there would be more restrictions than this! Which of these are valid variable names? What about other punctuation in variable names? e.g., @#$/?{}[](). Is 17 allowed as a variable name? What about 0out?

[gaow]

@pcarbo those are not, but i was not listing because people will mostly assume they do not work for parameters thus do not use them. Even if they do, i'll surely throw an error message. I'm just listing the ones that are normally allowed in one language but not another (1,2), one that people may very likely commit a mistake for (4) and two that would work with other languages but DSC does not allow (3,5).

[gaow]

Still pending tests in DSC, but I believe this is no longer an issue (we've done some work on SoS to have it relaxed). I changed the label from later to soon to add more tests on the DSC part.

[jdblischak]

@gaow I ran into this exact issue today (DSC 0.3.2 and SoS 0.18.4). That's why the names of my simulation modules all end in _name. When I tried to use, e.g. b_0_0, it threw an error.