Standardize settings inheritance

This work is part of https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/11

Problem

Settings set at the admin or group level are sometimes shown at the project level. Sometimes the two settings have no bearing on each other. Sometimes settings set at the group level cascade to projects in the group. Sometimes cascading settings are able to be overridden, sometimes they are shown in a locked state.

We are visually inconsistent in the way we signal cascading settings
When setting something at a parent level, it's not always clear how it will or will not impact children

Goal

Standardize logic and visual treatment of setting inheritance, and document in Pajamas.

Use cases

Case	Example
Setting exists at Group and Project level, but have no relationship	Deploy tokens
Setting set at Group level and shown at Project level, but not able to be overridden	Default branch
Setting set at Group level with option at group level with option to allow overrides	Shared runners
Setting set at Group level but can be overridden at project level	Integrations
A group of settings set at the Group level, but can be overridden at the Project level	Jira integration
Setting set at the project level and shown at the merge request level, but not able to be overridden	Squashing commits
Setting selected at a parent level, can not be overridden by a child object	Merge request approval settings
Setting set a group level can be overridden at a subgroup level if permitted	Delayed project deletion