I can ensure that my artifact is not modified when workflow is used to deal with a normalized process

See live mockup: https://s.codepen.io/enalean/debug/dace752a350bcecdad1003e505bc9992

This is the continuation of story #12189. It is split to be more manageable.

It covers:

• Retrieval of "frozen" fields through the REST API (see below)
• Handling of "frozen" fields in the Angular Artifact Modal: Kanban, Scrum Planning and Test Management do not yet show or handle well "frozen fields".

Technical details for REST and the angular Artifact modal

After analysis, we can't go forward with our previous plan for the REST API. In story #12189, we wanted to add a "workflow_state" property to field values returned by the GET /artifacts/{id} REST route. But for story #12188 we will be dealing with fieldsets. As we want a consistent solution for both of these stories, we had a problem with our initial plan. In Tuleap, fieldsets do not change with the state of the artifact. They are always the same for all artifacts of a given tracker. We can't really say that they have a "value", so it does not make sense to output them in the REST representation of artifacts. So, we can't add a "workflow_state" property to them.

We made another plan instead. Today, the artifact representation from the GET /artifact/{id} REST route returns a "minimal" tracker representation with only a few information. Upon receiving a special parameter (to be defined) for this REST route, we will instead output a "complete" tracker representation that will take into account the workflow state of the artifact and will tell us which fields are "frozen" for this particular artifact.
The artifact modal code will then use that representation to handle and display "frozen" fields.

About the REST choice of implementation
==================================

Here is the thought process:

=> We don't want to have a workflow_state because of inconsistency plus the fact that it is yet another thing to read
=> We want to recompute permissions on the fly instead so that it's clear what you can or can't do
=> We can't on a Tracker level because a tracker has no Artifact context
=> We could add a parameter to the /trackers/:id route to pass a changeset id because those permissions do rely on the changeset itself (state)
=> This is akward, as the /trackers/:id is really about structure
=> We add it to the /artifacts/:id because there, there is the artifact and changeset context

Overall, the idea is that wether we put it in /trackers or /artifacts, we blend the routes: Either /trackers becomes changeset aware, or /artifacts becomes structure aware. We went for the second solution for three reasons mainly:

Those new workflow post-actions (hidden/read-only) are a new paradigm. The old structure vs values way does not work anymore in this context as structure is now dependent on values. We thought the second solution was the easiest to deal with for a futur "us" who will add more of those things. We first wanted to make it default (no `tracker_structure_format` parameter), but as it is querying more informations and thus might be a bit slower, we went for protecting it behind this parameter. (We benchmarked the difference leading us to this decision).
If we make a parallel with the web UI, the tracker defines the structure of an artifact, but what does an artifact really look like is dependend on the artifact, you only discover it when you open the artifact page. Moreover, this is going to be even more true as we move in this read-only/frozen fields and hidden fieldsets direction, both dependent on the workflow's current state.
If we put it in the /trackers route, when you want to know what you can or can't submit and what you can or can't show (in the case of hidden fieldsets), you need to query the artifact, then you need to query for it's changesets, then you need to query the /trackers with the parameter of the changeset you want to get the structure in a changeset awaare way.