[PLAT-3643] Ensure app_type is consistently resolved

[imjoehaines]

Goal

This fixes a couple of issues with app_type — we now always use the value set by a user (if one is set) and integrations should now always set the correct value

For example, before this change Que would have an app type of 'rails' when running in a rails app. This is because the Que integration has to run when it's loaded and so sets its app type before Rails does

Now we always use the new detected_app_type property internally (this should only be used within Bugsnag) so that we know any user provided value will be set as the regular app_type. Most integrations can then safely overwrite the detected_app_type with the exception of Rails and Rack — these integrations can run with other integrations (e.g. Que in Rails) and so need to make sure they don't overwrite an already set value

Tests

Automated tests for the app_type exist in #616 and tests for app_type when integrations are run inside a Rails app exist in #618. This branch is separate so that we can fix the bug before those PRs are reviewed (they're pretty huge!)

Shoryuken is missing automated tests because it's a bit more complicated to setup (it needs a mock SQS server); I've tested this manually for now, but we'll add Maze Runner tests for this later

Review

For the submitter, initial self-review:

• Commented on code changes inline explain the reasoning behind the approach
• Reviewed the test cases added for completeness and possible points for discussion
• A changelog entry was added for the goal of this pull request
• 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
  • 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