Feat: Add Card:can_sell() API method

[NeatsTopFoo]

Identical to other API method patches - But from what I can see, looks like it needs to be in better_calc.toml? As the area where the API method needs to be directly follows an eternal check and the next thing after that is a return.

May need to be moved to center.toml

Additional Info:

• I didn't modify api's or I've made a PR to the wiki repo.
• I didn't modify api's or I've updated lsp definitions.
• I didn't make new lovely files or all new lovely files have appropriate priority.

[nh6574]

Looks good to me! The only comment is that context in that function is never really used in a vanilla, but I'm sure it doesn't hurt to pass it.
I added lsp definitions for now, I'll leave it open to see if anyone has any comments before merging.

[nh6574]

Ok, taking a second look I spot two issues: First the patch returns two values when can_sell_card only returns one. Second, it might be a bit confusing to make the function need to explicitly return a boolean instead of boolean|nil.

[NeatsTopFoo]

Ok, taking a second look I spot two issues: First the patch returns two values when can_sell_card only returns one. Second, it might be a bit confusing to make the function need to explicitly return a boolean instead of boolean|nil.

Yes. Although this is just directly lifted from other API implementations, my thought process was that since this would operate based on the developer addition of a function to modded Joker implementations that operate in the same way, with similar expectations, that this could be potentially leveraged with further refinement in case there's some kind of feasible use case for a second return value. I personally can't think of a use case (I did initially think of something potentially involving Eternal, but developers can and should just hook SMODS.is_eternal in that circumstance to achieve their desired effect), but I decided to leave it in, in case someone was able to think of a reason why two return values should be parsed from can_sell

If it does turn out that there isn't a feasible use case, I don't mind removing the second return value and just expecting it to return a boolean, for simplicity.

[nh6574]

In that case the second value would be added alongside whatever feature uses it. I don't see a reason for it to be here.