v3.3.0 — connect spans for predis (incl. Sentinel), and db.connect that survives a re-registered database provider

Both changes below add spans without any configuration change. Apps on
predis, and apps where db.connect was being dropped, will see new
redis.connect / db.connect spans and db.client.connection.create_time
observations after upgrading: about one per connection per request, two for
predis behind Sentinel. Turn them off with
TELEMETRY_INSTRUMENT_REDIS_CONNECT=false / TELEMETRY_INSTRUMENT_DB_CONNECT=false.

Added

• redis.connect for predis. The handshake was only timed for
  phpredis, because predis opens the socket on the first command and
  timing its connector would report object construction. predis clients
  are now handed a connection factory whose connections time their own
  connect (DNS, TCP, TLS and the AUTH/SELECT init commands) when it
  actually happens. Every node goes through that factory, so under
  Sentinel a cold request shows one span for the sentinel asked and one
  for the master it named, each with the address actually dialled. A
  connection that sets its own predis connections option is left alone.

Fixed

• db.connect spans no longer disappear when another provider registers
  the database services again. The connection factory was replaced with
  singleton(), so any provider registered later that ran
  DatabaseServiceProvider::register() again (a package provider that
  extends it without overriding register() does exactly that) silently
  rebound db.factory. The db.connect span and the
  db.client.connection.create_time histogram were gone, and the connect
  time showed up as a slow first query instead. The factory is now
  decorated with extend(), like redis, and survives the rebinding.