finally remove garbleActionID hack

Our cache is now robust against different Go package build inputs
which result in exactly the same build outputs.
In the past, this caused Go's cache to be filled but not ours.
In the present, our cache is just as resilient as Go's is.

main.go

@@ -1011,27 +1011,6 @@ func (tf *transformer) transformCompile(args []string) ([]string, error) {
 		if err != nil {
 			return nil, err
 		}
-		// It is possible to end up in an edge case where two instances of the
-		// same package have different Action IDs, but their obfuscation and
-		// builds produce exactly the same results.
-		// In such an edge case, Go's build cache is smart enough for the second
-		// instance to reuse the first's build artifact.
-		// However, garble's caching via garbleExportFile is not as smart,
-		// as we base the location of these files purely based on Action IDs.
-		// Thus, the incremental build can fail to find garble's cached file.
-		// To sidestep this bug entirely, ensure that different action IDs never
-		// produce the same cached output when building with garble.
-		// Note that this edge case tends to happen when a -seed is provided,
-		// as then a package's Action ID is not used as an obfuscation seed.
-		// TODO(mvdan): replace this workaround with an actual fix if we can.
-		// This workaround is presumably worse on the build cache,
-		// as we end up with extra near-duplicate cached artifacts.
-		// TODO: can we remove this now with the better caching?
-		if i == 0 {
-			src = append(src, fmt.Sprintf(
-				"\nvar garbleActionID = %q\n", encodeBuildIDHash(tf.curPkg.GarbleActionID),
-			)...)
-		}
 
 		// We hide Go source filenames via "//line" directives,
 		// so there is no need to use obfuscated filenames here.