(core): allow a way to determine if context value is (explicitly) passed in or if default was used

### Describe the feature

Apologies if the title is confusing. I am trying to figure out the best way to word it.

Essentially, referencing the docs here on the different ways that a "context" variable can be set:
https://docs.aws.amazon.com/cdk/v2/guide/context.html#context_construct

So there are 6 different ways, which is useful to know. In my specific use case, I have a snippet in my `~/.cdk.json` which sets a default value for a context value -- it looks actually exactly as so:

```json
{
...,
"context": {
"stage": "ritvik"
}
}
```

That's fine, but there is great fluidity with this setup. For instance, I can omit this sample `stage` context variable, and my CDK app still receives a default value of my name (thanks to the setup I have above):

```console
cdk deploy
```

And ofc, within my app code, I can easily retrieve value of context key as using sample code to demonstrate below:

```ts
app = new cdk.App()
app.node.tryGetContext('stage') // evaluates to 'ritvik'
```

And then additionally, yes I can also explicitly pass in a context value from the command-line:

```console
cdk deploy -c stage=jonas
```

Now let's see, the crux of the problem here is that in my CDK app I'm on unsure footing of how can I determine if context was passed in. That is, say if user actually specified a context value explicitly in command-line, or if context value was a default that was found somewhere else like my `~/.cdk.json` file or something for instance.

The reasoning here is, let's say based on the AWS account id, which I get from `CDK_DEFAULT_ACCOUNT` environment for ex, I want to auto-determine stage or environment to deploy app to, if it's not passed in.

However, currently in my CDK app it is _difficult_ to do this. I'm not sure if there's a method which exposes context info or metadata at that level, i.e. which can show me clearly if a value for that context key was passed in via command-line or if it is coming from a different source -- tbh I'm not too worried about knowing *which* source it was at this present moment, just that it was using a default value from another source.

Hopefully this clarifies it better, but essentially this is a feature request from me to see if A) this is currently possible or not from within CDK code, which my app can leverage or B) to request the same functionality, as I think this would be cool to have and would enable a lot of workflows such as a sample use case I have outlined above.

Thanks!

### Use Case

I think i have outlined it above! Please correct me if wrong xO

### Proposed Solution

Not sure if the *easiest*, but my suggestion could be to expose debug or metadata information captured by AWS CDK already, just so that it is in the publiclly exposed API.

Let's break it down. Here's what I see from the console when I'm running `cdk deploy` with verbose output like `-vvv`:

```console
$ cdk deploy -c something=whoo -vvv
[16:43:00] CDK toolkit version: 2.62.2 (build c164a49)
[16:43:00] Command line arguments: {
_: [ 'deploy' ],
c: [ 'something=whoo' ],
context: [ 'something=whoo' ],
v: 3,
verbose: 3,
...
[16:43:00] CLI argument context: something=whoo
...
[16:43:00] merged settings: {
versionReporting: true,
pathMetadata: true,
output: 'cdk.out',
app: 'npx ts-node --prefer-ts-exts bin/sample-ts-app.ts',
language: 'typescript',
context: {
stage: 'ritvik',
'@aws-cdk/aws-lambda:recognizeLayerVersion': true,
'@aws-cdk/core:checkSecretUsage': true,
...,
something: 'whoo'
},
```

Essentially, from above, the clouds start to clear a little bit overhead and one can start to see a few things pop up in the backdrop:
* Command-line arguments are captured by CDK CLI, that is note the line `c: [ 'something=whoo' ]` -- you can see it correctly captured the context key I passed in command-line. However, within app code, itself, for ex. in Typescript if i call `process.argv` for example, I see only arguments for how CDK called my app, but not arguments to CDK itself.
* However, even otherwise, inspecting command-line arguments to `cdk deploy` etc. is not vastly beneficial to my use case -- even though that could be mighty useful in and of itself. However, from above, if inspecting further with a looking-glass, under *merged settings* we can see that desired info Is correctly being populated there:

```
stage: 'ritvik',
something: 'whoo'
```

This makes sense, and truth be told it would hit the nail on the head if we confirm here that `stage: 'ritvik'` is correctly captured, even though such a value is not being passed in from the command-line.

Of course that is great, however the real use case here is being able to distinguish source of the context value -- i.e. was user actually set a value from the command-line itself? One can tell easily that no, not in this particular case, therefore the value must be coming from another source -- hence default value is being substituted, which agreed coincidentally is also desired behavior.

However, I am curious to know specifically, what is ideal or best way to tell with a surety that a default value is being provided for a particular context key or variable for example -- acknowledging that the exact source which is providing the context value is not needed to be known or more specifically to be exposed in any manner, at least in the scope of this particular use case.

### Other Information

_No response_

### Acknowledgements

- [X] I may be able to implement this feature request
- [X] This feature might incur a breaking change

### CDK version used

2.62.2 (build c164a49)

### Environment details (OS name and version, etc.)

Mac OS X (M1, Version 2.6.3)

Start by tracing how the CDK CLI captures context arguments and how merged settings reach app.node.tryGetContext('stage'); process.argv does not expose the CLI arguments. Determine an API that distinguishes an explicitly supplied context value from a value loaded from ~/.cdk.json or another default source, then verify that the distinction is available inside the CDK app.

Written by the indexing model from the issue text.