Modularize build process

[bmcdonald3]

Summary

The approach taken in this prototype was adding a map that maps from command strings to first class functions and removed the majority of commands from the main select cmd statement so that they would not be required with every Arkouda build. A ServerModules.cfg configuration file was added that takes the name of modules to include in the build, one per line, and generates import statements for those modules and adds their messaging functions to the command map only when in the configuration file to avoid compiling files that are not desired in a given Arkouda build.

Using the configuration file

Running make on this branch compiles Arkouda just like today with all modules included, and that is because the ServerModules.cfg file has all of the module names included by default. To build Arkouda without a module, all that is needed to do is comment out the module that you would like to exclude from that file and rerun make.

Additionally, in the case where a user has multiple configuration files, for example, the user can specify which configuration file will be used to generate the import statements by setting the environment variable ARKOUDA_CONFIG_FILE

Adding a module/converting an existing module

Assuming a module is already created that has its messaging functions, all that the user would need to do to add that module into a build is
(1) add a registerMe() (name up for discussion...) function in their file adding each function to the command map that looks like this:

proc registerMe() {
  use CommandMap;
  registerFunction("my-cmd", myCmdMsg);
  registerFunction("my-cmd2", myCmdMsg2);
}

(2) add the module name to the ServerModules.cfg file
(3) add a client-side function to handle the call

Remaining work

In the future, we would like to add the ability to add modules from any directory into this build to allow a user to easily plug in their own modules. Currently, this PR is limited to modules in the src/ directory.

[glitch]

This looks pretty good to me. I pulled it locally and ran a few builds / test runs, etc.

Obviously if you comment modules out tests will fail/hang etc. but since this is meant for development use there is an expectation that you know what you're doing.

In the future we may need to figure out some type of module dependency management and dynamic inclusion/exclusion for unit tests (maybe through the use of pytest marks), but that's another story for another time ;)

Nice work!

[glitch]

@bmcdonald3 The pydoc looks good to me 👍

[mhmerrill]

looks ok to me