Fixed determining the builder name

[GrahamCampbell]

Depends on bugsnag/bugsnag-php#572. Closes #369.

[tomlongridge]

What's the reason for moving this to bugsnag-php? I wouldn't have thought we want to add Symfony dependencies there in order to keep in framework-neutral. Can't we keep this functionality in bugsnag-laravel?

[GrahamCampbell]

Well, the PHP notifier still doesn't depend on symfony. It just uses it if it's available. We could actually delete the symfony code entirely if we really wanted.

[tomlongridge]

OK, not depend in the Composer sense but I would say for the bugsnag-php library to reference any framework-specific code should be avoided. I don't want to cause a breaking change by removing it - I was anticipating fixing the include path and maybe adding a test of when Process class doesn't exist (do we even support a version of Laravel when this doesn't exist?)

[GrahamCampbell]

I wouldn't say deleting this code is a breaking change. It's just the internals of the library. We were not getting the process class instance from the container, so users had no opportunity to mess with it.

[snmaynard]

I would generally favor an approach that means we have bugsnag-php that includes plugins for all the php frameworks we want to support. This is how ruby/python work and it means we don't have dependency issues. If that is the way it could be built, I would be generally supportive of that - cc @kattrali

[tomlongridge]

We've discussed this and agreed that there's no need for the Symfony code as there's no reason the native way of executing process calls wouldn't work. So we can merge this and close bugsnag/bugsnag-php#572.