Cache EIR UUIDs per Bluetooth address outside the pairing_cb_t

Currently, EIR UUIDs are cached inside the pairing control block. This
means EIR UUIDs belonging to device A can overwrite the EIR UUIDs
belonging to device B. Subsequently, if SDP fails for device A, we would
happily fetch the EIR UUIDs we know of (Device B's) and report it to the
Java layer. This is clearly incorrect.

Fix this by storing the EIR UUIDs per bdaddr. Upon failure of SDP, send
the EIR UUIDs belonging to the device for which SDP failed to Java and
then clear those EIR UUIDs so that we do not store them in memory for
longer than desired.

We are now using an LRU Cache to store the EIR UUIDs corresponding to
each discovered bdaddr. The cache can have EIR UUIDs for upto 128
devices.

1 BD_ADDR = 6 bytes
1 set of, say 6, 128-bit UUIDs = 96 bytes
=========================================
128 entries = 128*(6+96) = 13,056 bytes ~ 13KB of memory usage

If pairing is never done for certain devices after discovery, then
entries for these previously seen devices will always stay there in the
cache until the cache fills up with 128 entries at which point the
oldest entry will be replaced with the newest one.

Therefore, this CL adds a permanent memory footprint of about 13KB.

Bug: 242350646
Tag: #refactor
Test: tested it manually by forcing only EIR UUIDs to propagate to the
Java layer and also tested the case where zero EIR UUIDs exist and an
empty UUID is sent to the Java layer

Ignore-AOSP-First: Cherry-pick

Change-Id: Id3c4f7efd44c724a9451f31388d96d8f6119c1ba
(cherry-picked from commit 17db20332ef500ee0ad2d0b659002ba9a5182bc6)