Refactor DataModule to be more robust

[siddharth-krishna]

From #250 (comment):

Btw, I also realized that this isn't how Enums are "supposed" to be used. The "value" of an Enum should be a unique value, and the "names" are symbolic names that make the code cleaner/more robust. I think the canonical way of doing this would be to define an enum like

from enum import Enum, auto
class DataModule(Enum):
    base = auto()
    syssettings = auto()
    ...

and then having a mapping from Enum values to regexs/patterns path_to_DataModule or something, which is then used in _find_type to match the given path and then it returns a DataModule. This way, the method module_type will not have to return module_type.name but can return module_type instead, which is a DataModule object, which is useful down the line if some other transform wants to use some Enum method/cookbook. Or in order to have more type information in the DataFrames, as the data_module_type column can be of type DataModule instead of string.

See also: https://docs.python.org/3/howto/enum.html#enum-cookbook

While we're refactoring, we should also:

• Adjust the processing order of tfm tables #251 (comment)
• Adjust the processing order of tfm tables #251 (comment)

[olejandro]

@siddharth-krishna, would it be good / practical to include some constraints on data modules as part of this?
Things I can think of:

• there should be only one syssetting data module
• there can be only one trans submodule for base and each subres data modules
• there can be only one main submodule for trade and demand