Add new options for passing regexes to project root and strip path

[imjoehaines]

Goal

Allow using the bugsnag-php options for setting the project root and strip path as regexes, rather than just strings

This adds two new options, project_root_regex and strip_path_regex, which can be used instead of the existing project_root and strip_path options to allow setting them as regexes, as introduced in https://github.com/bugsnag/bugsnag-php/pull/514

This is a continuation of https://github.com/bugsnag/bugsnag-laravel/pull/348

Changeset

Added

• Two new configuration options:

  'project_root_regex' => env('BUGSNAG_PROJECT_ROOT_REGEX'),
  'strip_path_regex' => env('BUGSNAG_STRIP_PATH_REGEX'),

  These take presendence over the existing project_root and strip_path options if they are also provided

• More tests for path resolution, building off of https://github.com/bugsnag/bugsnag-laravel/pull/395

Changed

• Some of the existing path resolution code was leading to incorrect project root and strip path values being set, for example:
  • when a strip path value is configured, we only set the project root path if one wasn't provided. If both strip path and project root are given, no project root is set
  • when only strip path is configured, we set the strip path and then immediately overwrite it with a new path with "/app" appended by calling setProjectRoot. These issues have been fixed in this branch

Tests

More unit tests have been added, building off of https://github.com/bugsnag/bugsnag-laravel/pull/395

Discussion

Alternative Approaches

Outstanding Questions

Linked issues

Related to bugsnag/bugsnag-php#514 Related to #348

Review

For the submitter, initial self-review:

• [x] Commented on code changes inline explain the reasoning behind the approach
• [x] Reviewed the test cases added for completeness and possible points for discussion
• [x] A changelog entry was added for the goal of this pull request
• [x] Check the scope of the changeset - is everything in the diff required for the pull request?
• This pull request is ready for:
  • [ ] Initial review of the intended approach, not yet feature complete
  • [ ] Structural review of the classes, functions, and properties modified
  • [x] Final review

For the pull request reviewer(s), this changeset has been reviewed for:

• [ ] Consistency across platforms for structures or concepts added or modified
• [ ] Consistency between the changeset and the goal stated above
• [ ] Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• [ ] Usage friction - is the proposed change in usage cumbersome or complicated?
• [ ] Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• [ ] Concurrency concerns - if components are accessed asynchronously, what issues will arise
• [ ] Thoroughness of added tests and any missing edge cases
• [ ] Idiomatic use of the language