JPI plugin Manifest lacks Plugin-Class attribute when Gradle project was previously cleaned.

To reproduce:
1. have a basic gradle project with gradle-jpi-plugin that creates some jenkins plugin
2. run: ./gradlew clean
3. run: ./gradlew clean jpi - the resulting hpi plugin contains "faulty" Manifest w/o Plugin-Class attribute
4. run: ./gradlew clean jpi - the resulting hpi plugin contains Manifest with Plugin-Class attribute

The problem lies in JpiPlugin.groovy#configureJpi (line with: project.afterEvaluate):

     project.tasks.findByName(LifecycleBasePlugin.ASSEMBLE_TASK_NAME).dependsOn(jpi)
        project.afterEvaluate { <---
            jpi.archiveName = "${jpiExtension.shortName}.${jpiExtension.fileExtension}"
            jpi.extension = jpiExtension.fileExtension
            jpi.manifest.attributes(attributesToMap(new JpiManifest(project).mainAttributes)) <--
        }

This piece runs the code that collects attributes for Manifest just after "evaluation" aka "configuration" phase, i.e. when sources are not even built yet or the folder 'classes' is old (as it originates from previous build, like in #4 - clean is done after evaluation/configuration).
Of course some attributes are being acquired by scanning generated classes, for example the problematic Plugin-Class attribute is produced only when hudson.Plugin exists and this file appears in classes folder as a result of the assemble task (created by PluginSubtypeMarker extending javax.annotation.processing.AbstractProcessor).

I had to use the following workaround in my gradle file to ensure the Plugin-Class attribute is in place regardless of the state of the project:

task workaround << {
 project.jpi.manifest.attributes(org.jenkinsci.gradle.plugins.jpi.JpiManifest.attributesToMap(new org.jenkinsci.gradle.plugins.jpi.JpiManifest(project).mainAttributes))
}
project.tasks.findByName(org.jenkinsci.gradle.plugins.jpi.Jpi.TASK_NAME).dependsOn(workaround)

Apparently this issue was introduced in JENKINS-31426