New search method to return custom fields + bonus missing idReadable

[andreasciamanna]

As per #19, IssueEndpoint.search method does not return the issue's custom fields.

This forces developers to run additional requests for each issue returned by the search to get the required data.

This is inefficient.

This PR aims to solve the main issue of the missing custom fields.

I also added idReadable to ReducedIssueImpl (as a separate commit), as I think it's a fundamental property of an issue.

Long story

I initially tried to reuse the IssueEndpoint.search method using generics, but the implementation parameter, required by BaseEndpoint.getResourceWithFields, prevented me from doing that.

I've also tried the overload pattern, but I still struggled with that implementation parameter.

I ended up defining a new searchIssues method that returns Issue[] (instead of ReducedIssue[]) and uses IssueImpl (instead of ReducedIssueImpl).

An ideal option might be to redefine IssueEndpoint.search, which would introduce a breaking change.

[shanehofstetter]

Hi @andreasciamanna First of all thanks, that is a nice improvement!

I think it might be better to extend IssueEndpoint.search in a way that it can do both. This could be achieved by introducing an option like reduced: boolean to the method, which would be true by default (to keep the current behaviour). Usage would be like this for example: youtrack.issues.search("foo bar", { reduced: false }). What do you think?

[andreasciamanna]

@shanehofstetter, sorry for the late answer. I've been quite busy with other projects.

Your suggestion makes sense to me, and it was my first approach.

However, IssueEndpoint.search already has a second optional argument: paginationOptions: PaginationOptions = {}.

Doing what you suggest would require one of these options:

1. Extend PaginationOptions with a reduced : boolean;, which I find semantically incorrect, though probably the most effortless change to implement.
2. Add a third optional argument as such: public searchIssues<Issue>(query: string, paginationOptions: PaginationOptions = {}, outputOptions: OutputOptions = {}): Promise<Issue[]> (OutputOptions is just a name made while I was writing this).
3. Use TypeScript's approach to overloading. I never entirely managed to make it work as I wanted. I tried in this case and didn't manage to make it work reliably.

At this point, I prefer to close this PR and leave things as they are.

[andreasciamanna]

However, I would love it if we could release a version that includes the first commit (73cd914a560262733d5898c8b852f2ad65dbb569).

I'll move it to a separate PR.