Aviod reexported item ids by replacing them with source ids

[zjp-CN]

This will improve search cost for a trivial item in many places:

• compare id directly without touching IDMap (though we can aviod IDMap by comparing the suffix id with target id)
• avoid unnecessary recurisve: search for a defining item from reexported is indirection

current case1

2024-03-22T17:10:46.010455Z  INFO term_rustdoc::tree::id: found same id through reexport item src="0:208-0:2387:2234" target="0:2387:2234"
2024-03-22T17:10:46.010604Z  INFO term_rustdoc::page::content: jumpable_ids=[JumpableId { y: 0, x: 11..15, id: "0:2387:2234" }, JumpableId { y: 1, x: 8..13, id: "0:2709:236
0" }, JumpableId { y: 2, x: 8..13, id: "0:2709:2360" }, JumpableId { y: 3, x: 21..26, id: "0:2709:2360" }, JumpableId { y: 4, x: 14..22, id: "0:2909:2368" }]
2024-03-22T17:10:46.010995Z  INFO term_rustdoc::page::page_scroll: succeed to jump to "Cell"

0:208-0:2387:2234 and 0:2387:2234 are the same... so we can make item id in outline 0:208-0:2387:2234 be mere 0:2387:2234 to aviod touching hashmap.

[zjp-CN]

Pitfalls

When reexported id becomes defining id, line states are affected if multiple module with same id happen to be on screen:

• when user want to expand one of them, the real result is all of them will be expanded
  • this bring bad UX when user expand the one except the first:
    • we don't control how thing goes when modules are expanded out of sight, thus lines (and the cursor) are changed out of control
    • even in sight, due to check_if_can_return_to_previous_cursor behavior, you'll see the cursor jumps to the previous one!