O3-5332: Add initial Growth Chart app

[dilankavishka]

Requirements

• This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
• My work is based on designs, which are linked or shown either in the Jira ticket or the description below. (See also: Styleguide)
• My work includes tests or is validated by existing tests.

Summary

Created the Growth Chart App

Screenshots

Related Issue

https://openmrs.atlassian.net/browse/O3-5332

Other

[dilankavishka]

@anjula-sack @denniskigen Could you review this please?

[anjula-sack]

Can you update this with more details like a small description of growth chart, scope, implementation plan and current status? @dilankavishka

[anjula-sack]

Missing end of line here

[anjula-sack]

Why form engine's package.json is updated? @dilankavishka

[NethmiRodrigo]

Thank you kicking this off @dilankavishka! I hope this doesn’t sound harsh, but a couple of things (that applies to your other PRs as well):

1. I see that you’ve broken down the tickets, which is good, but they are slightly a bit too broken down. This isn’t sufficient enough of work done in one PR to be merged in (especially since this is the community repo). It should be a working functionality that is hooked up to the API. For example, this PR would be a combination of your current changes and the work in O3-5333 : Fetch Patient Data #2951.
2. It is a requirement to have unit tests and E2E tests in the same PR as the one you introduce the functionality.
3. In the case of O3-5334: Add WHO growth standards JSON data #2954, we don’t have usually have data loaded in the frontend modules in the form of JSONs. We typically utilise the initializer module to load metadata and configure them through content packages. I’m not quite sure how that would work here since there is no backend module that would take care of actually saving that metadata. I suggest either asking this on talk or on your ticket and tagging folks from the platform team. Making it so that the metadata is from content packages, also makes sure that its configurable, ie, any implementer would be able to just change it to use their own standard data.
4. I see that you’ve made a table version, but I see that we need a chart, but no requirement for a table in the wiki.
5. Ideally, we should build this under a feature flag, until we are sure that its ready (especially since this is in the patient chart itself)

[dilankavishka]

Thank you so much for the feedback @NethmiRodrigo !

I understand the concerns about the PR. I’ll adjust my approach and combine the related changes into a single PR going forward. would it be okay if I close other two PRs and combine their changes into this PR, and then continue all future work on this branch to deliver the complete functionality in a single PR?