Add initial issue-reporting models, API clients, and Redux boilerplate

[dpasque]

What Does This PR Add/Change?

Sorry this PR is so big! This adds a lot of core modeling and infrastructure that makes sense to add at the same time.

Initial issue reporting configuration models

This adds a "first take" set of data models that are core to Bugomattic. Bugomattic will be primarily driven by a dataset that defines issue reporting preferences for different products and features (what we call here the ReportingConfig).

More specifically, this PR adds...

• The model for how that ReportingConfig will be stored in the database (which is a more hierarchical structure).
• The transformed models to be used by the client app (which consist of a flattened, "normalized" version of the ReportingConfig, and indices that help with searching).
• The Redux state model wrapping those transformed ReportingConfig models.

This PR does not add any index shapes at the time, as what kind of searching we will support is still TBD.

Seams for different API implementations

Ultimately, for the production version of Bugomattic, we will bundle the application and add those bundles to an internal site backed by an internal API.

However, we also need to support local testing and development!

This PR adds the seams that will easily allow supporting both in the future. We define the ApiClient as an interface. We will ultimately have a local and production implementation of that interface. The local version will just return faked values to support local development and testing. The production version will make real calls to the REST API.

This PR adds the initial local implementation of the ApiClient. That dependency is ultimately injected through Redux...

Redux boilerplate

After looking into a million different "best practices", patterns from other Automattic apps, and the realistic needs of Bugomattic, I decided that we will rely primarily on Redux to...

1. Handle the UI state
2. Pass down the ReportingConfig to needed components
3. Inject the API client and handle web request lifecycles (through thunk middleware and async thunks)

Keeping with current best practices, we use the ReduxJs Toolkit.

This PR adds...

• The essential boilerplate for the redux store
• The reducers, selectors, and async thunks for loading and transforming the reporting config
• Testing utils to make it easier to unit test components that need the store (and need API requests)

Testing Instructions

I've added a fake version of the issue reporting configuration in src/api/local/local-reporting-config-response.json. I've also added a debug component that shows that config in its normalized & indexed form.

To see that...

• Clone this repo and check out the PR branch
• yarn install
• yarn start

Points of feedback I'm especially interested in...

• What do you think of the model for the issue reporting configuration? Does it seem to have the right level of detail? Is it intuitive?
• Does the Redux boilerplate and architecture make sense?

Issues

Related to #
Closes #

[dpasque]

After an architecture discussion, I'm actually going to put this back in progress.

I had been planning on ultimately adding ReactQuery and redux, but had planned on holding off for now and just adding them down the road.

However, it seems like this PR is probably the best place to add them as they'll change some of the architecture introduced here.

[john-legg]

Although I'm mostly unfamiliar with the React/Redux changes being made, I did my best to review the code and check for issues. I also ran the application locally and everything worked as expected.

During my sync with Dan, he walked me through the changes and explained how everything worked. In order to not block Dan from continuing on with his work, we agreed to merge this mostly-boilerplate PR. As I keep learning more about React/Redux, I'll continue going over the code to see if there's any suggestions I might have for him. Great work so far, @dpasque ! 🎉