Consolidate fee_amount and amount_needed

[csralvall]

Description

Before this commit fee_amount and amount_needed were passed as independent
parameters. From the perspective of coin selection algorithms, they are always
used jointly for the same purpose, to create a coin selection with a total
effective value greater than it's summed values.

This commit removes the abstraction that the use of the two parameter
introduced by consolidating both into a single parameter, target_amount, who
carries their values added up.

Resolves: #641

Notes to the reviewers

I just updated old tests and didn't create new ones because almost all changes
are renames and "logic changes" (like the addition of the selection fee) are
tested in the modified tests.

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added tests for the new feature
• I've added docs for the new feature
• I've updated CHANGELOG.md

Bugfixes:

• This pull request breaks the existing API
• I'm linking the issue being fixed by this PR

[danielabrozzoni]

Concept ACK, a small comment :)

[evanlinjin]

Concept ACK for me.

This PR is rather straight forward, and for the context on my work with multi-descriptor support (#486), it would be good to merge this PR soon (since I will also be modifying the wallet/{mod|coin_selection}.rs files).

Other than the concerns mentioned in #662 (comment), I think this PR is good to merge.

[danielabrozzoni]

Please rebase to fix the conflicts, then I'll ACK :)

[danielabrozzoni]

Code review ACK 6493bbf

[csralvall]

Rebased with master.

• I've added an extra line to the CHANGELOG.md about the new meaning of
  fee_amount in CoinSelectionResult which wasn't explicitly described before.
• I've removed the Resolves: ... part of the commit as I've realized it creates
  a lot of automatic logs in related PRs and Issues, each time we add new changes,
  duplicating info and making issue navigation cumbersome.
  At the end, it's the maintainer who will put that line in the merge commit.
  Maybe we can use some format to avoid the trigger and at the same time suggest
  the fixed issues to the maintainer.
  If you think it's not a serious issue, I can continue writing commits like
  before.

[danielabrozzoni]

tACK 6eb299b

[danielabrozzoni]

I rebased by myself, now it's ready for merge

re-ACK e8df3d2 - I tested with the fuzzer, run it for 13,000,000 iterations, couldn't find any crash :)