split build types?

[laroque]

@nsoblath and re-inspired by #30 ...
At times I've wondered if the sub-packages built by cmake could have different build types. For example, maybe I want to build katydid or psyllid at DEBUG, but would be happy for scarab to be at RELEASE. That would make it easier to keep track of the debugging statements from the code I'm actually working on and would eliminate the symptom that resulted in this PR (without disabling a feature set from within the package).

I haven't looked into what would be involved at all, which is why I hadn't posted before, but given the open PR it seems worth throwing this out there for comment.

[nsoblath]

This is an interesting question. Here's my initial take on an implementation and the unanswered questions it raises:

• Add a project-specific build type variable, {PROJECT}_BUILD_TYPE so that the build can be controlled by the user.
• The initial values of the build-type variables need to be set somehow from the top down.
• During the configuration stage the values of the build-type variables need to set CMAKE_BUILE_TYPE.
• How does CMake know whether to set the values of the build-type variables from the top-level variable (i.e. to set the initial values) or to use the values of the build-type variables to set CMAKE_BUILD_TYPE?
• Can CMAKE_BUILD_TYPE be changed for a submodule?

Another option would be to make better use of the ability to change logging levels for different loggers. This would require being better about using a single logger in each package (or a set of loggers in a package in a predictable way). We would also need to make sure we understand how to set the logging levels.