Port Compose Desktop ProGuard support to IntelliJPlugin

[mrjameshamilton]

Pull Request Details

This is a first attempt at porting the ProGuard support from Compose Desktop Gradle Plugin to the IntelliJ Gradle Plugin.

Description

Recently, ProGuard support was added to the Compose Desktop Gradle plugin by adding a Gradle task which configures & executes ProGuard, and a simple DSL configuration.

This PR copies the AbstractProguardTask, ProguardSettings and related utility code.

Some of the utility code is probably not required and can be removed but currently I copied & pasted complete files.

I've slightly modified the AbstractProguardTask to make it work in the IntelliJ Gradle Plugin: mostly for collecting the library jars (which should maybe be done instead in the IntelliJ Plugin?) and making the mainClass optional.

I've added a configureProguardTask in the IntelliJPlugin to configure the plugin and set the input & output files.

A plugin block can be added to an IntelliJ Plugin project:

tasks {
     ...
    proguard {
        configurationFiles.from("proguard-rules.pro")
       dontobfuscate.set(false)
    }
}

Running the ./gradlew proguard command currently produces a proguarded jar in build/lib/proguard/ but this may not be the most appropriate location. The publish task should also be able to publish this version of the jar instead of the original.

A default ProGuard rules file is added to the resources. We should add some default rules to the configuration that make sense for IntelliJ Plugin projects.

We should probably also print the various logging files by default into the build folder; especially the mapping.txt file when obfuscation is enabled (-printmapping mapping.txt).

Motivation and Context

Provide a simplified integration for ProGuard shrinking, optimization and name obfuscation compared to e.g. using the current ProGuardTask

How Has This Been Tested

Currently manually tested on a small sample: please advise on how this should normally be tested.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have included my change in the CHANGELOG.
• I have added tests to cover my changes.
• All new and existing tests passed.