refactor: improve the logic for setting options in readMany and search

[JadenKim-dev]

PR Checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

During the validation stage, withDeleted was assigned redundantly with default values, and this was being serialized in the query(nextCursor).
setSort and setOrder both set the sort and order, making their roles unclear.

What is the new behavior?

Default value for withDeleted is assigned only in the intercept method, and only user input is serialized in the query.
setSort and setOrder only set values. Calculated sort and order values are passed by the readMany/search interceptor.

Does this PR introduce a breaking change?

• Yes
• No

Other information

separated PR from #579

[jiho-kr]

First of all, thank you for your contribution. ( I'm short on time these days :) )

setSort and setOrder provide the caller with the choice of using Sort or FindOptionsOrder<T>.

setSort and setOrder both set the sort and order
This is probably the meaning from the perspective of read-many.request.ts only.

The change in this PR will force the use of setSort and setOrder
to required rather than optional, in calls to crudReadManyRequest.

And it will create confusion to the caller to write duplicate functions.

[JadenKim-dev]

First of all, thank you for your contribution. ( I'm short on time these days :) )

setSort and setOrder provide the caller with the choice of using Sort or FindOptionsOrder<T>.

setSort and setOrder both set the sort and order
This is probably the meaning from the perspective of read-many.request.ts only.

The change in this PR will force the use of setSort and setOrder to required rather than optional, in calls to crudReadManyRequest.

And it will create confusion to the caller to write duplicate functions.

Thank you for your suggestion!
As you mentioned, it seems more semantically accurate to call either setSort or setOrder but not both.

The reason for this change was that I found it somewhat confusing to pass the default sort value together when calling setOrder.
I would modify only that part.