fix: Replace print statements with logging and logging modular level (PR2)

[PredictiveManish]

Description
This PR standardizes the logging implementation across libyear_util to follow Python best practices and solve #3313:

Changes Made:

1. Added module-level loggers: Each module now uses logger = logging.getLogger(__name__)
2. Eliminated print statements: All console output now uses proper logging
3. Fixed inconsistent patterns: Removed logger parameter passing in favor of module-level loggers
4. Improved import organization: Removed duplicate imports

This PR partially solves #3313
Split of #3478
Notes for Reviewers

• Consistent logging behavior across the codebase
• Better control over log levels and output
• Follows Python logging best practices
• Easier debugging and monitoring
• Cleaner separation of concerns

Testing

• Enabled Python logging locally
• Verified log messages emit via logger.info
• No changes to control flow or task behavior
• Verified logging output locally with logging.basicConfig(level=INFO).

Signed commits

• Yes, I signed my commits.

[MoralCode]

This PR partially fixes #3313

Try not to put the word "fixes" right before the issue citation since thats what triggers github to link it to the underlying issue in a way that will close it when this merges.

its a tricky balance between citing the changes/connecting the issue and still having the multi-part changes work

[MoralCode]

while this PR does replace some prints with proper logger calls, It also introduces some less-than-ideal practices (especially global variables) that i think outweigh the benefit of the logs

[MoralCode]

more global variable logging that needs fixing

[sgoggins]

@MoralCode : @ABrain7710 can set me straight if I am not understanding correctly, but our logging is designed to create logs that are distinct to the different data collection utilities/tasks Augur performs. This is one of those tasks. It would create much more object-creation overhead if a logger instance were instantiated in each method for this task. I am assuming that by global you mean global across methods in this file, which is for one task.

I think there may be a trade-off between the downside of all the methods in a task sharing a logger and the cost of creating and destroying logger objects in each method.

[MoralCode]

my feedback here is sort of addressing that problem.

youre right that we dont want to create a logger per method. But i also dont want to be using a global variable that all our methods just... use because then the dependencies/expectations each method requires to run are not clearly laid out in the signature.

What I would like to see here is that, instead of getting a logger variable from global scope, the logger would be passed in as a parameter like we do in many other places. Then we can instantiate it when we set up the task and pass it to the entrypoint, which will pass it down through any other functions that get called.

This will also help us run tasks individually in isolated contexts, like unit testing, more easily.