Pointer Icon Refactor: Load resources for system icons before drawing

In this refactor, we ensure that we load the resource for system icon
types (as opposed to custom icons that use TYPE_CUSTOM) once in the
system before drawing the icon, instead of resolving the resource in the
app using the app context.

The main reason for this refactor is to simplify the pipeline by
eliminating the unnecessary step of resolving the system icon resource
using the app context. The app-resolved resource IDs are already being
ignored, because the native code only caches the icon by type and not
the resource IDs. This refactor only makes that behavior explicit in the
code, so there should be no behavior changes.

Notable changes:
- Do not resolve the resource IDs of system icons in
  PointerIcon#getSystemIcon().
- There is no need to register a display listener in PointerIcon.
- When parceling a system icon, only send the type.
- Get the loaded system icon in native code directly from the java
  InputManagerService, instead of loading it using native code.
- Cache loaded icons in the java IMS so that bitmaps don't need to be
  copied when used by multiple pointer controllers.

To recap, the Java PointerIcon object can be in one of three states:
1. Custom icon: The PointerIcon holds a custom bitmap provided by the
   app to use as the cursor icon.
2. System icon (Unloaded): The PointerIcon object refers to specific
   system icon differentiated by the TYPE_* constants. The bitmap of the
   system icon is not yet loaded in this state.
3. System icon (Loaded): The PointerIcon object refers to a specific
   system icon, and it holds the bitmap for that icon, which has been
   loaded into memory.

Apps only have the ability to create icons in states 1 and 2, since
they don't need to load the system icon bitmaps that are drawn by the
system.

Bug: 293587049
Test: manual
Change-Id: I6f79ca0611019501e0ca02c0edfa16d39578e927