[Bug] contract reports ether as locked when ether is sent in Yul

[0xalpharush]

The following contract reports ether as locked despite it being sent in a Yul block

contract FPLockedEther {
  receive() payable external {}

  function yulSendEther() external {
    bool success;
    assembly {
      success := call(gas(), caller(), balance(address()), 0,0,0,0)
    }
  }
}

Contract locking ether found:
	Contract FPLockedEther (locked-ether.sol#1-13) has payable functions:
	 - FPLockedEther.receive() (locked-ether.sol#2-3)
	But does not have a function to withdraw the ether
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#contracts-that-lock-ether

It could be that the IR is incorrect here as it should not be a SOLIDITY_CALL

Contract FPLockedEther
	Function FPLockedEther.receive() (*)
	Function FPLockedEther.yulSendEther() (*)
		Expression: success = call(uint256,uint256,uint256,uint256,uint256,uint256,uint256)(gas()(),caller()(),balance(uint256)(address()()),0,0,0,0)
		IRs:
			TMP_0(uint256) = SOLIDITY_CALL gas()()
			TMP_1(address) := msg.sender(address)
			TMP_2 = CONVERT this to address
			TMP_3(uint256) = SOLIDITY_CALL balance(uint256)(TMP_2)
			TMP_4(uint256) = SOLIDITY_CALL call(uint256,uint256,uint256,uint256,uint256,uint256,uint256)(TMP_0,TMP_1,TMP_3,0,0,0,0)
			success(bool) := TMP_4(uint256)

[bart1e]

The following code seems to cause this bug:

slither/slither/solc_parsing/yul/parse_yul.py

Lines 728 to 729 in 6356492

	else:
	ident = Identifier(SolidityFunction(format_function_descriptor(ident.value.name)))

It probably should be LowLevelCall instead. The problem is, that LowLevelCall requires destination in its constructor to be of type Union[LocalVariable, LocalIRVariable, TemporaryVariableSSA, TemporaryVariable], but at the point the code is invoked, none of these variable types is created (we only have CallExpressions, at least for the provided yulSendEther implementation).

I may try to fix this issue, but I need more information about it:

• should I use LowLevelCall here?
• if I should, then what to provide as destination and result parameters?

So far, LowLevelCall objects are only created using convert_to_low_level invoked on a HighLevelCall object, so they aren't created for Yul code.