Add top-level config ref

Nobody has claimed this yet.

**Is your feature request related to a problem? Please describe.**
We at Vector team deploy the same service with 99% the same config for different projects (e.g. Metatile-Queue-Populator/ Retiler). The only difference might be the queue which I'm subscribing to or DB name/ S3 Bucket/ directory in a S3 bucket. Currently, I'll have to create config-per-instance and maintain each one of them (which will result in duplicate config - in the current state of schema and service).
I also expect that I would be able to override properties from the shared config.

**Describe the solution you'd like**
I would like to be able to top-level `$ref` a "shared" config in the specific project config's and inherit it's config and override the properties which are project-specific.

**Describe alternatives you've considered**
Change the schema (again).

**Additional context**
This will enable us to create ts-server-boilerplate shared config and many more copy-paste config
An example
```
// shared schema
{
"foo": {
"type": "string"
},
"bar": {
"type": "string"
}
}

// shared config
{
"foo": "avi1",
"bar": "avi2"
}

// "full" schema
{
"$ref": "#/ref/to/shared/schema",
"baz": {
"type": "string"
}
}
// => which results to
{
"foo": {
"type": "string"
},
"bar": {
"type": "string"
},
"baz": {
"type": "string"
}
}

// "full" config
{
"$ref": "#/ref/to/shared/config",
"baz": "avi3"
}
// => which results to
{
"foo": "avi1",
"bar": "avi2",
"baz": "avi3"
}

//another valid edge-case option
{
"$ref": "#/ref/to/shared/config",
"foo": "avi420"
"baz": "avi3"
}
// => which results to
{
"foo": "avi420",
"bar": "avi2",
"baz": "avi3"
}

```

Points to consider:
I think we should also have [Pick](https://www.typescriptlang.org/docs/handbook/utility-types.html#picktype-keys)-[Omit](https://www.typescriptlang.org/docs/handbook/utility-types.html#omittype-keys) `$ref` support in order to, as you probably already guessed, pick a config value/ omit one.

No files, tests, or entry points are named in the issue. Start by reviewing the existing schema and config resolution behavior, then clarify how top-level $ref inheritance, property overrides, and Pick/Omit should interact. Done means the supported semantics and edge cases are specified and covered by tests.

Written by the indexing model from the issue text.