Add support for publishing artifacts

[tudortimi]

Gradle source dependencies are not a feature that is in focus. Many aspects lag behind "regular" dependencies (e.g. gradle/gradle#26392, gradle/gradle#25312, version info is wonky when calling dependencyInsight, etc.).

We could emulate "regular" dependencies by publishing archives containing the source files, together with some metadata (e.g. what to compile, in what order, what options, etc.).

[tudortimi]

Plan:

• add support for publishing archives (Add publishing of source archives #133)
• add support for consuming archives (Add consuming of source archives #135)
• write compile spec when publishing archive (Publish metadata for SystemVerilog compilation together with sources #136)
• use compile spec when consuming archive (Use metadata for SystemVerilog compilation when consuming source archives #139)
• unify writing and reading compile specs before expanding scope (Unify writing and reading compile specs #142)
• implement handling of SystemVerilog private incdirs (Handle SystemVerilog private incdirs in published HDVL sources archives #144)
• implement handling of SystemVerilog exported incdirs (Handle SystemVerilog exported header dirs in published HDVL sources archives #145)
• implement handling of C (Handle C source files in published HDVL sources archives #147)
• clean up usages of hard coded paths (e.g. related to conventional source locations) (Clean up usages of hard coded paths of source conventions #148)

[tudortimi]

Currently, we're producing an XML for the compile spec. The idea behind the XML was that it's possible to write using code from the standard library. With newer Java libraries, this isn't the case anymore. We might as well produce a JSON file (like Gradle also does for its rich metadata) using Jackson. The JSON file would also be much easier to read. The Jackson code for handling it might also be easier than the JAXB code.

[tudortimi]

Switched to JSON for compile specs (#149).