revise replaceable events handling

[mleku]

by accident due to the debugging process for the race conditions in the relay interface and eventstore for replaceable events code that used to find and delete it has been commented out, as this extra step often triggered a race condition

a simple test shows that a kind 0 event being updated currently now adds the event but the order of the results and the number that come back from a query without a limit set is undefined behaviour

in order to make this work as clients expect while exposing the ability to return the history of replaceable events, as most replaceable events are intended to be one per pubkey, the following changes are needed:

• [x] before applying the limit filter, sort the results by timestamp in reverse chronological order so newest is the first item and the one usually returned - this is already how the priority queue heap works in the query process, but it is being refactored into a struct instead of slice type
• [x] default any filter with a request for replaceable events to return 1 if no limit is specified
• [x] sort query results in descending created_at timestamp order, newest first, there isn't any way to specify this and clients usually will sort it but why make work for clients that are usually less efficient
• [ ] investigate NIP-66, which has some relation to returning replaceable event history

[mleku]

keeping issue open until we get clarification on draft NIP-66 but the rest is done, merging into main

[mleku]

nip-66 is being released tomorrow, hopefully this will happen tomorrow

adding descending timestamp sort order by default on results, newest first