Squash nested sinatra/rack request span

[TonyCTHsu]

Motivation

For Sinatra/Rack instrumentation, the middleware stack architecture renders nested flamegraph for span. Although it is technically correct, the user experience with such UI is suboptimal.

---

What does this PR do?

Instead of instrumenting nested middleware stack of Sinatra or Rack, the implementation changes to only instrument the top of the stack. This means the UI would display only one rack.request and sinatra.request.

Some changes followed after skipping the subsequent middlewares:

1. sinatra.app.name tag is removed from the sinatra.request span, but still present for sinatra.route span. Since the app name only make sense when a route is matched by its individual app.
2. When no route matched, sinatra.request span would no longer tagged with sinatra.route.path, since none of the route matched(sinatra.route span is absent as well).

Other improvement: Configuration is all it needs to instrument Sinatra, no longer need to register for each Sinatra app.

---

For Classic Sinatra app

---

For Modular Sinatra app with Sinatra::Router

class Acme < Sinatra::Base
  # # Use Sinatra::Router to mount different modular Sinatra applications
  use Sinatra::Router do
    mount ::Health
    mount ::Basic
  end

---

For Modular Sinatra app chaining with use

class Acme < Sinatra::Base
  # # Use Sinatra App as middleware
  use Health
  use Basic