Some ARM-HF PLT stubs identified at wrong address

### Description

I have a binary compiled for ARMHF that contains PLT stubs to math library function `log`.
When I load the binary with `cle` and use the `find_plt_stub_name` function, it does not identify the stub at the address that `objdump` shows.

In the below disassembly, the stub is at `0x518` but `cle` maps it to `0x51c`, which means it probably mis-identifies the start of the stub.
I tracked down the issue to the `MetaELF._load_plt` function, whose comments say that this is essentially performed by machine code pattern matching. I have not tried understanding the implementation of `_load_plt` but it looks like the pattern I have in my binary is not captured.

For now, I am checking both `addr` and `addr+4` to find the plt stub name, and it works fine.

This plt stub is called from a tail-call optimized function. I guess this is why it has extra instructions, but I am not sure of this.

Disassembly from `objdump`:

```
...
0000050c <__stack_chk_fail@plt>:
50c: e28fc600 add ip, pc, #0, 12
510: e28cca10 add ip, ip, #16, 20 ; 0x10000
514: e5bcfabc ldr pc, [ip, #2748]! ; 0xabc

00000518 :
518: 4778 bx pc
51a: e7fd b.n 518
51c: e28fc600 add ip, pc, #0, 12
520: e28cca10 add ip, ip, #16, 20 ; 0x10000
524: e5bcfab0 ldr pc, [ip, #2736]! ; 0xab0

00000528 <__gmon_start__@plt>:
528: e28fc600 add ip, pc, #0, 12
52c: e28cca10 add ip, ip, #16, 20 ; 0x10000
530: e5bcfaa8 ldr pc, [ip, #2728]! ; 0xaa8
...
```

### Steps to reproduce the bug

Github wont let me attach the ELF binary. I am attaching the full disassembly from `objdump`.
[myfunc.txt](https://github.com/angr/cle/files/14078510/myfunc.txt).

Let me know if you need anything else.

### Environment

`cle` version is 9.2.86

### Additional context

_No response_