v3 has now been released officially

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license

Allow `cdk diff` command to create a change set that imports existing
resources.

The current `cdk diff` command implicitly calls
CloudFormation change set creation, providing high-level details such as
"add", "delete", "modify", "import",
and etc. like the following:

```s
$ cdk diff
[-] AWS::DynamoDB::Table MyTable orphan
[+] AWS::DynamoDB::GlobalTable MyGlobalTable add
```

However, when the resource is meant to be imported, the `cdk diff`
command still shows this as add. Adding `cdk diff
--import-existing-resources` flag to show the new resource being
imported instead of `add`.

```s
$ cdk diff --import-existing-resources
[-] AWS::DynamoDB::Table MyTable orphan
[←] AWS::DynamoDB::GlobalTable MyGlobalTable import
```

Here is the underlying CFN change set JSON output
```json
[
  {
    "type": "Resource",
    "resourceChange": {
      "action": "Import", # NOTE THAT THIS SHOWS "Import"
      "logicalResourceId": "MyTable794EDED1",
      "physicalResourceId": "DemoStack-MyTable794EDED1-11W4MR8VZ0UPE",
      "resourceType": "AWS::DynamoDB::GlobalTable",
      "replacement": "True",
      "scope": [],
      "details": [],
      "afterContext": "..."
    }
  },
  {
    "type": "Resource",
    "resourceChange": {
      "policyAction": "Retain", # Note that this is "Retain"
      "action": "Remove",
      "logicalResourceId": "MyTable794EDED1",
      "physicalResourceId": "DemoStack-MyTable794EDED1-11W4MR8VZ0UPE",
      "resourceType": "AWS::DynamoDB::Table",
      "scope": [],
      "details": [],
      "beforeContext": "..."
    }
  }
]
```

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license

---------

Signed-off-by: github-actions <github-actions@github.com>
Co-authored-by: Momo Kornher <kornherm@amazon.co.uk>
Co-authored-by: Rico Huijbers <rix0rrr@gmail.com>

Deprecated in favor of @aws-cdk/toolkit-lib, a newer approach providing
similar functionality to this package. Please migrate.

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license

…s is set (#502)

The `Date` class allows the following for values: `new Date(value:
number | string | Date)`, but sometimes does not work as expected.
That's essentially what we are doing because we are storing the string
value of the date in the tags and the conversion back to a date doesn't
work correctly.

A deep dive into the issue with Dates:

```ts
console.log(Date.now()) // 1747346265800
console.log(Date(1747346265800)) // Thu May 15 2025 18:06:11 GMT-0400 (Eastern Daylight Time)
console.log(Date('1747346265800')) // Thu May 15 2025 18:05:57 GMT-0400 (Eastern Daylight Time)
console.log(new Date(1747346265800)) // 2025-05-15T21:57:45.800Z
console.log(new Date('1747346265800')) // Invalid Date
```

I seem to have been unlucky with how I tried to create the date from a
string. Also, the resulting dates with a number of milliseconds versus a
string of milliseconds is _slightly_ different, 18:06:11 versus
18:05:57...

This _was_ attempted to be unit tested but in the unit test I mistakenly
mocked the tag to be an ISO String which _is_ a string so it had no
problem getting converted into a Date. This test has been updated.

Because we pessimistically handle errors; we just treated this as a
nondeletable asset. I have added an integ test that tests this scenario
and confirmed on my own local set up that this fixes the issue.

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license