Axe `send` `receive` feature separation

[DanGould]

these were separated so that v1 http client senders and v1 http server receivers were only using code they could actually deploy. Now that v2 is all client software, this distinction isn't really necessary and every sender should implement receiving as well.

[DanGould]

Because the main reason to keep send receive feature separation was to allow v1 send implementation with minimal dependencies, and those implementations are now deprecated, we will indeed axe the separation

We might have wanted this separation if for example we had an io feature implementation that included an opinionated web server for receive and HTTP client for send where the send client wouldn't want to depend on the server dependencies.

as discussed with @spacebear21 @nothingmuch

[DanGould]

One reason I can imagine keeping these is if you want strictly the payjoin::directory (#418) types and not send or receive.

In that case, I think it'd be better to have separate v1, v2, directory features where {v1,v2} had send & receive functionality and directory did not, which I think can still mean send and receive get axed.