Make Klib-related Gradle tasks public

[fzhinkin]

What was done:

• cleaned up klib-related tasks API
• rewrote code gluing up tasks together to utilize Gradle properties for proper dependency tracking
• made tasks public
• made some programmatic API classes used as tasks inputs serializable

Fixed #203

[shanshin]

Why File but not RegularFileProperty?
It seems that because of this, lateinit looks very unusual

[fzhinkin]

This change moves the property back from BuildTaskBase, so I left the same type. However, as this PR will break binary compatibility for the Compare task, it might be worth breaking it here as well and providing a more robust implementation in return.

[shanshin]

You can try to add a reliable field, but maintain backward compatibility.
In BuildTaskBase

    @get:Internal
    public abstract var outputApiFile: File

In KotlinApiBuildTask

    @get:OutputFile
    ...
    public val realOutputApiFile: RegularFileProperty = project.objects.fileProperty()

    @get:Internal
    public override var outputApiFile: File
        get() = realOutputApiFile.get().asFile
        set(value) = realOutputApiFile.set(value)

• I didn 't check it )

[fzhinkin]

The main issue here is that we definitely want to phase these old properties out and ask users to migrate to realXXX ones, but old properties already claimed good names :(

[shanshin]

Will changing property type break a lot? Because if we don't change it now, it will stay that way for a long time.

[fzhinkin]

A few weeks ago I had an impression that there are a lot of projects relying on these properties. After checking it once again, it seems like I was wrong and there are only a couple of projects on GH relying on it.

Originally, I was reluctant to make breaking changes as I wanted to limit the scope of the release to KLib support only. But as there are some other breaking changes already, it might be worth changing this part too and provide a migration guide for those who use corresponding properties.

As it was previously discussed elsewhere, currently BCV is mostly concerned with its own source compatibility as there are no other projects (beside Adam's BCV-MU) extending the BCV, so it should be more or less fine to change property types now.

[shanshin]

Should we link a public task so tightly to a specific extension?

[fzhinkin]

These tasks are tightly bound to BCV anyway. The thing that worries me more is implicit initialization of properties, but I'm not sure that making initialization explicit and moving it to BinaryCompatibilityValidatorPlugin will make a big difference for now