Refactoring FmpClient class

[sorndotdev]

Continuation of conversation here: #25 (comment)

[andyyngo]

I asked Gemini what it thinks about FmpClient, and it has a few suggestion, which looks quite good
Here is the chat https://g.co/gemini/share/bf6c730e45ad

The basic idea is to split each type of operation into classes:

• Search
• Directory
• Company
  etc

and then making calls like this
Old way:

client.searchByName("Apple");
client.incomeStatements("AAPL", ...);

New, improved way:

client.search().byName("Apple");
client.statements().incomeStatements("AAPL", ...);

[sorndotdev]

I agree with the idea of refactoring this class, as long as we maintain a single 'entry point' for the user. I plan to use this library in another project, and I’d prefer to interact with just one API class.

---

I disagree with Gemini that we should use DCL:

DCL is considered a concurrency anti-pattern. But more importantly, it'd be a micro-optimization/overkill here.

From "Java Concurrency in Practice by Brian Goetz":

[andyyngo]

Checkout this PR #33
Let me know what you think about this approach.

[sorndotdev]

Yes, that’s a good first step. Let’s create a new clients package and rename FmpSearchService → FmpSearchClient so they’re not confused with the services that extends FmpService. Later, we can look into module-info.java to make the service package hidden from API users.