Feature/improve generator

[staleyLANL]

This PR has a variety of new things, many of them, but not all of them, related to the code generator.

I changed the terminology used for a couple of special nodes. Special nodes are the ones whose names begin with #, indicating that they need special treatment. (And, the # also guarantees that they can't conflict with valid C++ names that someone might use for classes generated by our code generator.)

Special nodes include, for example, #cdata and #pcdata, which are used in our primary Node data structure in order to represent what are called, respectively, CDATA and PCDATA nodes in XML.

The following two changes have been made:

1. #nodeName to #nodename. Other special nodes didn't use camelCase, so I decided this one shouldn't either. The GNDS manual had suggested using nodeName to encode a node's name in JSON -- something that must be done due to certain limitations of JSON relative to XML. We're apparently the first ones to create JSON-format GNDS files, and we already took it upon ourselves to add the # prefix. Therefore, changing another thing doesn't seem too unreasonable. In my opinion, camelCase feels distracting when used in this context. And, as already stated, we're now being consistent: all special node names are now entirely lowercase.

2. #attributes to #metadata. As with the node-name business described above, our earlier name (without the #) was suggested by the GNDS manual for use in JSON. Throughout GNDStk, we prefer the more-generic, less XML-biased term metadata, and decided to use it here.

For the above changes, tests and resource files, as well as verbiage in the documentation, were, of course, updated accordingly.

Editorial remark: GNDS codes from other institutions may end up doing things differently. For now, with JSON at least (which is where this is all relevant), we may be the first to support it, and have chosen this system. If there's disagreement, at some point, about how to handle special nodes, we can deal with that at that time. Perhaps, even if different GNDS codes choose to write things a bit differently, all could support reading GNDS files from anyone. That would just be a matter of accepting, say, either #metadata or attributes, and either nodeName or #nodename. Supporting a handful of such choices wouldn't create much complexity.

On other matters...

The code generator now allows "times" in place of "occurrence". We still accept the latter term, because GNDS specs have it, but the name "occurrence" was just getting me down. It's too verbose, and is easy to misspell. "times" is simply better, in my opinion. I've updated our prototype GNDS specs to use "times", but left "occurrence" in our copy of the full v1.9 specs.

I also made some changes (now, when it's still possible -- before the whole world is using GNDStk!!) to the functions that must be provided inside classes that derive from GNDStk::Component:

• namespaceName to NAMESPACE
• className to CLASS
• GNDSName to FIELD
• keys to KEYS

The uppercase names stand out, and indicate that there's something special about these functions (which there is: Component expects them). All of them being all-uppercase makes them more consistent with one another. Moreover, for non-GNDS libraries that somebody might want to build with the code generator, we anticipate that the all-uppercase names are less likely to conflict with names that might be used elsewhere in the class. What if someone wanted a node called keys, for instance (<keys> in XML)? Now, as long as a user of the code generator uses lowercase names, they'll stay lowercase when used as fields in other classes, and in getters and setters. So, no conflict. And, they'll be capitalized (e.g., keys to Keys) for class names. So, still no conflict with ALL UPPERCASE.

Another editorial remark: I don't take changes, like all the above, lightly. After GNDStk gets out there and takes the world by storm, changing such things would have the potential to break what users are doing. For now, before that happens, I'm taking opportunities, when I see them, to make changes that I think are for the better, before doing so would create problems for users.

In the or.hpp file, I fixed up a couple of comments that weren't quite right, and also added back (1) a certain constructor, and (2) a certain free function, that I'd removed in an earlier commit. I'd thought that neither of those were used, but then realized that it only appeared that way because the test suite wasn't completely testing all of or.hpp's functions regarding multi-queries.

And, with the above paragraph in mind: I added hundreds of lines of brand new multi-query test code to Node's call.test.cpp.

I've done some work with the code generator as well. Duh, this branch is called feature/improve-generator, so one would think that I'd done something that improves the code generator.

The changes.json file no longer needs the "string" to "std::string" change, because the code generator does that change automatically. Many entries in the present changes.json are super specific (say, relating to somebody's enums) and couldn't possibly be known, automatically, by the code generator. Others are very GNDS-specific, such as the change from "double" to "Double".

With the above modification, a user of the code generator might be able to simply not have a changes.json file. (The code generator already didn't require users to have it; just remove any "Changes" key/value pair in the main input JSON.) We'll still get string to std::string, and, unless we're working with an actual GNDS spec that might have GNDS-isms like the "double" node, other mappings probably just aren't needed. (We wouldn't even provide string to std::string, given that users could always write "std::string" in the first place, but figured that users would like it.) Note that in the unlikely event that you have your own "string" and don't want it changed to std::string automatically, you'd need to use a namespace prefix, e.g. "mystuff::string". But we don't think most people will write their own string.

The code generator has a few additional changes. The generated key.hpp file, which has Lookup<> and Child<> objects for the generated classes, #includes GNDStk.hpp, and itself is #included in each class file (and no longer needs to be #included in the version file). The class files thus no longer need to #include GNDStk.hpp, and also don't need a particular using directive that key.hpp now already provides for them. (Besides, we believe that someone who brings in a class file should automatically get the Lookup<> and Child<> objects. And, those are simple, so bringing them in automatically won't slow compilation by any significant amount. Note that we have retained the concept that generated class files should be usable independently, bringing in only the dependencies that they need. The modifications we've spoken of don't change that.)

The above changes, while relatively simple, make the file for each generated class just a few lines shorter and simpler. That's something we like, especially considering how many generated files we'll eventually have.

Finally, we dealt with a few fixmes, improved a bit of detail:: terminology, and made some simplifications in several Component-related files.