refactor: handle multiple unlock types in getInputsPreExpandedConfig

[VmMad]

Description of change

Fixes #1104

Type of change

• Bug fix (a non-breaking change which fixes an issue)

How the change has been tested

shimmer/transaction/0x02b8488d0cd5ff39d8ade27a73c11e85bbc46171e4479d60f194869d7ebdc7d1

Change checklist

Add an x to the boxes that are relevant to your changes, and delete any items that are not.

• My code follows the contribution guidelines for this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[begonaalvarezd]

unlock references can be transitive, so we need to follow the path until we find the signature

[begonaalvarezd]

there seems to be a bug, if you visit the tx of the original issue /shimmer/transaction/0x02b8488d0cd5ff39d8ade27a73c11e85bbc46171e4479d60f194869d7ebdc7d1 there is a basic output that doesnt expand its address unlock

[VmMad]

there seems to be a bug, if you visit the tx of the original issue /shimmer/transaction/0x02b8488d0cd5ff39d8ade27a73c11e85bbc46171e4479d60f194869d7ebdc7d1 there is a basic output that doesnt expand its address unlock

Issue reference: #1121