Addressed a memory leak in OSPF by fixing the improper deallocation of
area range nodes when removed from the table. Introducing a new function,
`ospf_range_table_node_destroy` for proper node cleanup, resolved the issue.
The ASan leak log for reference:
```
Direct leak of 56 byte(s) in 2 object(s) allocated from:
#0 0x7faf661d1d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7faf65bce1e9 in qcalloc lib/memory.c:105
#2 0x55a66e0b61cd in ospf_area_range_new ospfd/ospf_abr.c:43
#3 0x55a66e0b61cd in ospf_area_range_set ospfd/ospf_abr.c:195
#4 0x55a66e07f2eb in ospf_area_range ospfd/ospf_vty.c:631
#5 0x7faf65b51548 in cmd_execute_command_real lib/command.c:993
#6 0x7faf65b51f79 in cmd_execute_command_strict lib/command.c:1102
#7 0x7faf65b51fd8 in command_config_read_one_line lib/command.c:1262
#8 0x7faf65b522bf in config_from_file lib/command.c:1315
#9 0x7faf65c832df in vty_read_file lib/vty.c:2605
#10 0x7faf65c83409 in vty_read_config lib/vty.c:2851
#11 0x7faf65bb0341 in frr_config_read_in lib/libfrr.c:977
#12 0x7faf65c6cceb in event_call lib/event.c:1979
#13 0x7faf65bb1488 in frr_run lib/libfrr.c:1213
#14 0x55a66dfb28c4 in main ospfd/ospf_main.c:249
#15 0x7faf651c9c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 56 byte(s) leaked in 2 allocation(s).
```