Fat Jar Support

[mageddo]

Hey, I've created a new feature that I need in my use case which is:

Created a new feature at LibraryLoader so it will try to load the dll from inside the jar, it's useful so people don't need to worry about specifying paths and handling dll files.

I'm sharing my code in this pull request because with that we aren't too far to be able to create an automated continuous delivery to publish jacob dependency to maven central with the dll bundled, if you consider to merge this pull request then I can work to fix the issue #4 .

See another side features or fixes that I needed to achieve my objective:

1. Automated the java build with gradle which is capable to automatically run the junit tests and genrated the versioned jar.
2. I found that some files were with different encodings (utf16 and windows-1252) then they broken the build process, fixed that
3. Realized some tests are dependent on a specific environment installed tools, like excel or word, so named them as ManualTest this way we can run them separatelly when wanted but they won't run on default build process.

You can check the results of this pull request by typing:

$ ./gradlew build
BUILD SUCCESSFUL in 53s

$ dir build\libs
 Directory of G:\dev\jacob-project\build\libs

03/07/2023  01:45 AM    <DIR>          .
03/07/2023  01:45 AM    <DIR>          ..
03/07/2023  01:45 AM           243,244 jacob-project-1.21.jar
               1 File(s)        243,244 bytes
               2 Dir(s)  244,545,708,032 bytes free

[freemansoft]

1. Why did you rename the tests to be ManualTest. What are you trying to say with that? -
   1. Ah I see that in your comments
2. How does the build process change? The current build process is ANT driven. Are you totally replacing the Ant process with gradle?
   1. Ah I see some of that in your comments.
3. None of the README files were updated to document the new build process.

[freemansoft]

It looks like the gradle code builds the package but not the DLLs. So this is a partial build.

Some of the samples were in different character sets because they were part of defect reports related to character sets. A quick check makes it look like the source code is all UTF-8 CRLF.

The DLL is loaded by copying it from the jar file into a temporary file system. That is a slick way to work with a single bundle but I'm not sure relying on a temp file to load a DLL is a good idea. Feels like a security issue.