HID: Access JNI callback object when valid.

Usecase:
Perform BT off/on with HID connection in stress loop overnight.
Expectation:
BT should not crash, and should work normally after stress test.
Observation:
BT crash observed due to dereference of JNI object whch was NULL.
Coredump
=========================
pid: 4629, tid: 4711, name: BT Service Call  >>> com.android.bluetooth <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'art/runtime/java_vm_ext.cc:470]
JNI DETECTED ERROR IN APPLICATION: obj == null'
=====================
bt_btif : btif_hh_upstreams_evt: BTA_HH_OPN_EVT: handle=255, status =7
bt_btif : in, bd addr:00:1f:20:ea:ca:8b, prop type:4, len:4
bt_btif_dm: get_cod remote_cod = 0x00002540
I bt_btif : HAL bt_hh_callbacks->connection_state_cb
JNI DETECTED ERROR IN APPLICATION: obj == null
    in call to CallVoidMethodV
"BT Service Callback Thread" prio=5 tid=12 Runnable
  | group="main" sCount=0 dsCount=0 obj=0x12ca8b80 self=0xe7a84400
  | sysTid=4711 nice=0 cgrp=default sched=0/0 handle=0xd8f88920
  | state=R schedstat=( 75150605353 59660157373 74582 ) utm=3592
  stm=3923 core=4 HZ=100
  | stack=0xd8e8c000-0xd8e8e000 stackSize=1014KB
  | held mutexes= "mutator lock"(shared held)
  native: #00 pc 00377955  /system/lib/libart.so (_ZN3art15Dump
  NativeStackERNSt3
  __113basic_ostreamIcNS0_11char_traitsIcEEEEiP12
  BacktraceMapPKcPNS_9ArtMethodEPv+128)
  native: #1 pc 0035795d  /system/lib/libart.so (_ZNK3art6Thread9
  DumpStackERNSt3
  __113basic_ostreamIcNS1_11char_traitsIcEEEEbP12BacktraceMap+304)
  native: #2 pc 00250d79  /system/lib/libart.so (_ZN3art9JavaVMExt8
  JniAbortEPKcS2_+812)
  native: #03 pc 0025103d  /system/lib/libart.so (_ZN3art9JavaVMExt9
  JniAbortFEPKcS2_z+72)
  native: #04 pc 00284127  /system/lib/libart.so (_ZN3art3JNI15Call
  VoidMethodVEP7_
  JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+478)
  native: #05 pc 00005f81  /system/lib/libbluetooth_jni.so (???)
  native: #06 pc 00010d27  /system/lib/libbluetooth_jni.so (???)
  native: #07 pc 000657bf  /system/lib/hw/bluetooth.default.so (???)
=======================

Root cause:
For quick BT turn on/off cases there may be instances where callback from btif
is triggered even before callback object is created or cleanup path may clear
callback object just before stray btif callback call tries to access the same.

Fix:
Check if callback object is valid before trying to access the same

Test: Crash not observed in stress test with hid connection and BT on/off.

Bug: 35023377
Change-Id: Id9b526bfec2bf74d7110601f85e111088a1e7d76