*.links.task.yml: Drop parent_id/base_route in favour of "parent" like menu links

In general you have to understand that the different patterns, menu links, local actions, contextual links and local tasks
do have totally different usecases. The only common thing is that they provide a link with route names + parameters aka. a URL (which was provided by hook_menu()). Making it explicit that they work different helps, see http://legacy.python.org/dev/peps/pep-0020/
Peter described that point in his own words:

good DX is NOT ONLY about what you have type the 1st time, it should also be about reducing the WTF factor when you come back to it 6 months later or are looking at it as a novice.

When we started with local tasks in #2004334: Separate Tabs (MENU_LOCAL_TASK) from hook_menu() we wanted to decouple the hierarchy structure of local tasks from route names. So an example would have looked like the following. As you see, the route name did actually not mattered at all

views_ui_list_tab:
  route_name: ...
  title: ...
  tab_root_id: views_ui_list_tab
views_ui_settings_tab:
  route_name: ...
  title: ...
  tab_root_id: views_ui_list_tab
views_ui_settings_advanced_tab:
  route_name: ...
  title: ...
  tab_root_id: views_ui_list_tab
  tab_parent_id: views_ui_settings_tab
views_ui_settings_basic_tab:
  route_name: ...
  title: ...
  tab_root_id: views_ui_list_tab
  tab_parent_id: views_ui_settings_tab

People complained, so this got changed in #2107531: Improve DX of local task YAML definitions to contain less keys. Sadly that changed removed explicitness, but removed the amount of typing you
need.

views_ui.settings_tab:
  route_name: views_ui.settings_basic
  title: Settings
  base_route: views_ui.list

views_ui.settings_basic_tab:
  route_name: views_ui.settings_basic
  title: Basic
  parent_id: views_ui.settings_tab

views_ui.settings_advanced_tab:
  route_name: views_ui.settings_advanced
  title: Advanced
  parent_id: views_ui.settings_tab
  weight: 10

views_ui.list_tab:
  route_name: views_ui.list
  title: List
  base_route: views_ui.list

Maybe you have not realized, but there is a difference between "parent" and base_route (or tab_root_id as before). The parent describes
a hierarchical relationship, the tab_root_id/base_route describe a sibling relationship. I think not making this explicit will
especially be worse in terms of understanding. Why should the parent key work different, depending on the context.

Please don't consider this as a attack to you, its just the fact that we had all this discussion earlier as well.

I guess that level of understanding of the underpinnings of the menu system is not something I would expect to have to know in order to simply add some tabs to my module's admin interface (this is a very common task).

You wanna say that people should not actually understand what they are doing (creating siblings + hierarchies) but instead turn off their
brain and just write something together which seems to work, without any concrete clue what is going on, especially in the future,
when people actually have to reread their code/YML files? You proposal makes it incredible hard to change in the future, as you need much more context.
Previously you could read a single definition and know where it appears (root level, child level). With your proposal you have to move along the trail in order to figure that out. We need to take more metrics into account that the amount of keystrokes.

You will not convince me to use a hierarchic description for something non-hierarchical but well I won't fight here,
but at least let me quote someone from the community when I talked about your idea: "This makes no sense".

Talking about parent vs. parent_id, we went with the second one, to communicate clearly that these are plugins IDs, not route names or whatever.