LogJobStart was not being logged - FIXED

…saurabhnanda#38)

Many small changes were required, but the majority were mechanical
changes. With the exception of the `createJob`/`scheduleJob` family of
function, this should be mostly backwards compatible with existing
user code that does not use "internal" functions. Further discussion
about how to handle backwards compatibility is needed.

Note also that this commit by itself is NOT compatible with existing
databases. A future commit will address migration from existing to new
database definitions.

The intention is for this feature to have a negligable impact on
performance when the resource limiting features are not being used,
and only a minor impact when they are used. However, performance
testing has not yet been done.

Material changes inclue:

- New resource table
- New `resource_id` column in to job table
- New `cfgDefaultResourceLimit` configuration value
- New `createResourceJob` and `scheduleResourceJob` functions
- New `TableNames` type to carry the now multiple values needed
- Updated existing functions and queries to account for these changes
- Updated dequeueing queries to implement resource concurrency limits
- New `DevelDb` module to the `devel` executable to help ad hoc testing

TODO:
- Resource record management functions
- Migration functionality (need to discuss database versioning)
- Unit tests
- Performance tests
- Documentation updates
- Resource management UI

* setup a simple CI using GitHub actions

* describe a simple dev setup process

* build branches with pull requests against master, run build on multiple operating systems

* trigger CI for all branches

* always checkout the ref

* build only on pull_request events not to duplicate builds

* build only on Ubuntu

Because PostgreSQL limits notification payloads to 8000 bytes by
default, passing the full job record in the notification artificially
limits the job payload size.  By passing only required fields in the
notification, this limitation is removed.

…saurabhnanda#38)

Many small changes were required, but the majority were mechanical
changes. With the exception of the `createJob`/`scheduleJob` family of
function, this should be mostly backwards compatible with existing
user code that does not use "internal" functions. Further discussion
about how to handle backwards compatibility is needed.

Note also that this commit by itself is NOT compatible with existing
databases. A future commit will address migration from existing to new
database definitions.

The intention is for this feature to have a negligable impact on
performance when the resource limiting features are not being used,
and only a minor impact when they are used. However, performance
testing has not yet been done.

Material changes inclue:

- New resource table
- New `resource_id` column in to job table
- New `cfgDefaultResourceLimit` configuration value
- New `createResourceJob` and `scheduleResourceJob` functions
- New `TableNames` type to carry the now multiple values needed
- Updated existing functions and queries to account for these changes
- Updated dequeueing queries to implement resource concurrency limits
- New `DevelDb` module to the `devel` executable to help ad hoc testing

TODO:
- Resource record management functions
- Migration functionality (need to discuss database versioning)
- Unit tests
- Performance tests
- Documentation updates
- Resource management UI

Because there are unit tests that delete tabes, and now that there are
multiple table names in play, it seemed useful to explicitly implement
a deletion function. Becuase this deserved a comment, I also added
comments to the other externally useful functions in this module, and
rearranged the file a bit to highlight these defintions.

Now, if the environment variable "ODD_JOBS_TEST_DB_CONNECT" is set, it
will be used as a connection string for unit test.  If not, the
existing hard-coded default connection will be used.

This is useful when developing in a containerized environment.

This includes the changes that are on `fix/tests` branch.