Issue/120/check estimator columns

[hangqianjun]

Problem & Solution Description (including issue #)

This PR addresses #120 and implement the check_columns function in tables_io into the rail base classes.

Code Quality

• [x] My code follows the code style of this project
• [x] I have written unit tests or justified all instances of #pragma: no cover; in the case of a bugfix, a new test that breaks as a result of the bug has been added
• [x] My code contains relevant comments and necessary documentation for future maintainers; the change is reflected in applicable demos/tutorials (with output cleared!) and added/updated docstrings use the NumPy docstring format
• [x] Any breaking changes, described above, are accompanied by backwards compatibility and deprecation warnings

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 98.38%. Comparing base (30a570f) to head (ee912d9).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #164 +/- ## ========================================== + Coverage 98.35% 98.38% +0.02% ========================================== Files 45 45 Lines 2497 2536 +39 ========================================== + Hits 2456 2495 +39 Misses 41 41 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[hangqianjun]

Some notes with the PR (and my confusions):

• The check_columns functions (they are all called similar names) defined in tables_io as well as inrail.core.data and rail.core.stages all have **kwargs which are unspecified parameters needed when reading in the files, dependent on the file type. These parameters for now are not included, registered, or propagated through RAIL when running interactively or from a ceci pipeline. So, when these check_columns functions are called in a specific stage (informer & estimator), the **kwargs are omitted. This should be considered later on.
• The _check_column_names() function in rail.core.stages allows the input data to be a) a datahandle with just path, b) a datahandle with data, and c) an actual table of data. When running interactive mode, all stages will call set_data(), which will always give case b). I'm not sure when will cases a) and c) be required, perhaps when running in pipeline mode?
• I have added methods for check_columns for TableHandle, but not for qp files yet. Would be great if someone can give some suggestions on whether this is needed for qp files.
• Thenvalidate() function doens't exist in the ceci public release yet, so the dependence is changed to the ceci main branch in order to have the tests pass. We can wait until ceci has made a release to merge this.