Sparql-anything libraries should only depend on slf4j-api, not SLF4J implementations or logging configuration files

[LanAnd95]

The sparql-anything modules currently include SLF4J implementation dependencies (such as slf4j-simple) and logging configuration files (log4j.properties) in their published JARs. This causes conflicts for applications that consume these libraries and want to use their own logging implementation.

Running curl -s https://repo1.maven.org/maven2/io/github/sparql-anything/sparql-anything-parent/1.1.0/sparql-anything-parent-1.1.0.pom | grep -i slf4j -A2 shows:

        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-simple</artifactId>
        <version>1.7.7</version>
      </dependency>
--
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>1.7.7</version>
    </dependency>
--
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-simple</artifactId>
      <version>1.7.7</version>
    </dependency>

Similar issues appear in other sparql-anything modules like sparql-anything-json or if you try to grep log4j.properties.

When applications use sparql-anything as a library, this causes:

• Multiple SLF4J bindings warning: "SLF4J: Class path contains multiple SLF4J bindings"
• Unpredictable logging behavior: The wrong implementation may be chosen at runtime
• Forcing exclusion rules: Consumers must explicitly exclude slf4j implementations in their build files
• Assembly/fat JAR conflicts: Duplicate log4j.properties and other logging configuration files prevent clean builds
• Unwanted logging configuration: Library-provided logging configs can override application settings

[enridaga]

100% -- we should clean those up and leave only slf4j-api in all but the executable jars.