Fix apipkg lookup in GenerateExample of testing plugin

[tchssk]

This pull request updates the logic in the testing/generate.go file to improve how the example implementation package name is determined when generating test suites. Instead of deriving the package name using string manipulation, the code now extracts it directly from the file header metadata, making the process more robust and accurate.

Improvements to package name determination:

• Changed the method for determining the example implementation package name in GenerateExample to extract it from the file header's Pkg field, rather than constructing it from the service name using string manipulation.

Code cleanup:

• Removed the unnecessary import of the strings package from testing/generate.go.

[raphael]

Nice, I like the direction here. Reading the package from generated metadata is a lot nicer than reconstructing it from the service name.

One case I think we still need to handle: files only has the files generated during this goa example run. If the example service implementation already exists, Goa skips emitting <service>.go, so this loop can end up grabbing the package from some other generated file, like main or interceptors. Then the root suite file would be generated with the wrong package on reruns or when adding the testing plugin to an existing example project.

Could we either keep using the same API package derivation Goa uses for the top-level service implementation, or make this lookup target that specific top-level service file and handle the already-exists case explicitly? A small test for the existing-service-file/rerun case would be great too.