Add local-tasks to response

>And yes, you were right, It didn't work in this case too but I fixed it by completely remove tabs with forbidden access from render array before merge cache metadata, see patch

Not sure this really correct, since it would miss custom cache context / metadata added by special routes with custom access checkers + wrongly cache the results then. Also, it seems wrong that the patch only adds cache metadata from the #primary tasks, not the #secondary ones.

Not sure what the best solution here.

Variant A) It would be nice if we would have something like lazy-builders in the render array, so that we would be able to render missing bits after retrieving the entry from dynamic page cache. Maybe is there a way we could do this here, custom-coded for local tasks?

Variant B) We move local-tasks out of the response to avoid making requests harder to cache and introduce a new route for it. I don't see a large issue with the frontend triggering another page request for fetching & lazy-loading that information, but obviously it's not nice to bootstrap Drupal twice for logged in users for every page request.

What do you think?

Discussed approach:
- Have \Symfony\Component\HttpFoundation\JsonResponse provided json data
- Implement event subscriber onResponse that runs after dynamic page cache, just add local-task data hard-coded there to make sure it does not influence caching (later on we can make it easy to add mory lazy-generatd data for modules also)

thx, patch looks really good. only a minor remark:

+   * @var array
+   */
+  protected $source_data;

shoudl use camelcasing. also not sure about the wording, why "source" data? it'S just the data of te response, right? is "data" taken? in that case maybe "responseData" ?

also, please do not forget to set ticket to "needs review" when there is a patch to be reviewed.
Setting it / leaving it needs work now for the minor remark.

I tested this successfully as well, so let's get this naming remark done and let's commit then.