Initializing with tables in dedicated directory fails in 4.1.0

We have been using the 3.0.0 version for a few years and now tried moving to latest version 4.1.0. Our code no longer works because our tables are stored in a dedicated directory (not the jar file) which we simply pass to the Translator together with the table names during Translator instantiation.
But now library initialization fails because a default table resolver is created which tries to read resources from the jar file and then throws an exception ("directory does not exist").
As a temporary fix, we deactivated the creation of a new TableResolver in Louis.getLibrary():250 and uncommented the registration of the table resolver in Louis.getLibrary():312-316 (if (!tableResolverIsRegistered) { ... }
Then everything worked like a charm!

I agree that automatic table extraction from the associated jar file is very useful but it would be good to have some mechanism to avoid the problem for cases where tables are stored in the file system (which is more efficient for normal operation). One alternative might be to add a different table resolver which would be initialized to the directory or one might add a flag such as autoExtractTablesFromJar which is set to true by default but could be set to false in cases where the files are already in the file system.

Start in Louis.getLibrary(), especially the default table-resolver creation around line 250 and resolver registration around lines 312-316, then trace how Translator receives table directories and names. Reproduce initialization with tables outside the jar and compare it with the temporary change described in the issue. Done means filesystem-backed tables initialize successfully without breaking automatic jar-table handling.