build(deps): bump markdown-it and markdownlint-cli in /tools/linters (#532)

* build(deps): bump markdown-it and markdownlint-cli in /tools/linters

Bumps [markdown-it](https://github.com/markdown-it/markdown-it) to 13.0.1 and updates ancestor dependency [markdownlint-cli](https://github.com/igorshubovych/markdownlint-cli). These dependencies need to be updated together.


Updates `markdown-it` from 10.0.0 to 13.0.1
- [Changelog](https://github.com/markdown-it/markdown-it/blob/master/CHANGELOG.md)
- [Commits](markdown-it/markdown-it@10.0.0...13.0.1)

Updates `markdownlint-cli` from 0.22.0 to 0.35.0
- [Release notes](https://github.com/igorshubovych/markdownlint-cli/releases)
- [Commits](igorshubovych/markdownlint-cli@v0.22.0...v0.35.0)

---
updated-dependencies:
- dependency-name: markdown-it
  dependency-type: indirect
- dependency-name: markdownlint-cli
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>

* Update rules and markdowns

---------

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Rico Hermans <[email protected]>

Author: dependabot[bot]

.markdownlint.json

@@ -3,11 +3,14 @@
   "commands-show-output": false,
   "fenced-code-language": false,
   "first-line-h1": false,
-  "line_length": {
+  "MD013": {
     "line_length": 150,
     "tables": false
   },
-  "MD046": "fenced",
+  "MD034": false,
+  "MD046": { "style": "fenced" },
+  "MD049": false,
+  "MD050": false,
   "no-duplicate-heading": {
     "siblings_only": true
   },

README.md

@@ -8,7 +8,6 @@ future state of the libraries and to discover projects for contribution.
 [jsii]: https://github.com/aws/jsii
 
 **Jump to**: [What is an RFC?](#what-is-an-rfc) |
-[When to submit?](#when-to-submit-an-rfc) |
 [RFC Process](#rfc-process) |
 [RFC Life Cycle](#the-rfc-life-cycle)
 
@@ -403,7 +402,7 @@ Throughout this process, update the tracking issue:
 - Plan approved and merged (label: `status/implementing`)
 - Implementation complete (label: `status/done`)
 
-## State Diagram
+## The RFC Life Cycle
 
 The following state diagram describes the RFC process:
 

text/00110-cli-framework-compatibility-strategy.md

@@ -134,7 +134,7 @@ incompatible change to the _cloud-assembly-schema_ itself. This can, for
 example, be the removal of a property.
 
 > See concrete
-> [example](#rename-target-property-in-containerImageAssetMetadataEntry).
+> [example](#rename-target-property-in-containerimageassetmetadataentry).
 
 The proposed solution for this case is to run API compatibility checks using
 `jsii-diff`. We would treat _cloud-assembly-schema_ as a regular `jsii` module
@@ -416,7 +416,7 @@ function, and contains two validations:
 
 1. **Framework cannot be bigger than CLI.**
 
-   We have already [described](#step-3-validate-cli--framework) how to handle
+   We have already [described](#compatibility-validation) how to handle
    this validation.
 
 2. **CLI cannot be bigger than Framework.**

text/0079-cdk-2.0.md

@@ -314,7 +314,6 @@ match the first GA release, and the `latest` distribution tag will start
 tracking the versions of CDKv2. A new distribution tag called `latest-1`
 will be created to track the latest release of CDK `1.x.y`.
 
-[semantic versioning]: https://semver.org/#spec-item-9
 [pom version order]:
   https://maven.apache.org/pom.html#Version_Order_Specification
 [nuget versioning]:
@@ -396,8 +395,6 @@ branch to be the new `master`. At this point,
 - The PR check will be removed from the `master` branch. Let the deprecations on
   CDKv2 begin!
 
-[import rewrites]:
-  https://github.com/aws/aws-cdk/tree/master/packages/%40monocdk-experiment/rewrite-imports
 [lambda runtimes]:
   https://github.com/aws/aws-cdk/blob/b757d8856216152b03c1ed3ffe2f29719aff8c27/packages/%40aws-cdk/aws-lambda/lib/runtime.ts#L37-L63
 [rds oracle versions]:
@@ -516,8 +513,6 @@ used to track adoption of the new version. We will encourage customers to
 provide feedback on the upcoming new release using a pinned GitHub issue, and
 possibly other means.
 
-[version reporting]: https://docs.aws.amazon.com/cdk/latest/guide/tools.html
-
 ## General Availability
 
 After the _Developer Preview_ has been sufficiently vetted, a timeline for
@@ -566,8 +561,6 @@ dataset. Should adoption pick up too slowly, actions will be taken to understand
 the causes for slow adoption and identify opportunities to provide additional
 tooling to remove roadblocks and facilitate migration.
 
-[version reporting]: https://docs.aws.amazon.com/cdk/latest/guide/tools.html
-
 ## Deprecation of v1
 
 Based on the [maintenance policy](#aws-cdk-maintenance-policy), new feature
@@ -761,7 +754,7 @@ All users will perform the following to adopt CDK v2
 
 Users will naturally have to make additional changes when upgrading if they are
 relying on deprecated APIs or _old behaviors_ from feature flags that are being
-removed. A [migration guide](#migration-guide) will be written with details
+removed. A migration guide will be written with details
 about each individual feature flag and deprecated API that users may need to
 handle differently when upgrading.
 

text/0107-construct-library-module-lifecycle.md

@@ -43,7 +43,7 @@ Each stage in this document describes 3 distinct sets of activities:
 - **Exit criteria:** When these criteria are all met, a module can progress into
   the next stage. Note that, while all of the criteria here are necessary, they
   may not be sufficient. The module still needs to be chosen for maturation
-  using the [prioritization framework](#Construct-prioritization-framework).
+  using the [prioritization framework](#construct-prioritization-tenets).
 
 ## Stage 0 - CFN Resources
 
@@ -108,7 +108,7 @@ changes, we will author a Request for Comments (RFC) that outlines our design
 and publish it on the roadmap for feedback. We will also use pull requests to
 conduct construct reviews. In all cases, relevant RFCs, PRs, bugs, and feature
 requests that are in scope are linked in the module’s tracking issue for
-visibility. See [Appendix A](#Appendix-A:-GitHub-Artifacts) for an illustration
+visibility. See [Appendix A](#appendix-a-github-artifacts) for an illustration
 of how these GitHub artifacts are used and related to each other.
 
 ### Entry activities
@@ -369,7 +369,7 @@ modules to work on next:
   constructs but are still experimental.
 - _“Do the most difficult work first”_ - prioritize modules that have a large
   and/or complex API surface area that we know will take significant effort.
-  [Appendix B](#appendix-b:-module-complexity-t-shirt-sizes) proposes
+  [Appendix B](#appendix-b-module-complexity-t-shirt-sizes) proposes
   “T-shirt”sizes for each module in the construct library to identify work that
   falls into this category, and module owners are responsible for estimate this
   effort.

text/0192-remove-constructs-compat.md

@@ -812,7 +812,7 @@ The first two use cases have already been addressed by centralizing the
 ### 07-NO-SYNTHESIZE
 
 Version 4.x of the `constructs` library does not contain a lifecycle hook for
-synthesis as described [above](#the-synthesize-hook-is-no-longer-supported).
+synthesis as described [above](#07-no-synthesize-the-synthesize-hook-is-no-longer-supported).
 
 The reason this is not available at the base class is because the abstraction
 did not "hold water" as the AWS CDK evolved and new CDKs emerged. In the AWS
@@ -955,11 +955,11 @@ If we consider the various [reasons](#drawbacks) not to take this change, the
 main reason would be to simplify the
 [migration for users from 1.x to 2.x](#user-migration-effort). The major version
 2.x is already required to introduce monolithic packaging, and this change, for
-most users, is likely to be trivial (see [above](#breaking-changes)). Therefore,
+most users, is likely to be trivial (see above). Therefore,
 we believe this is probably not the correct motivation to reject this proposal.
 
-The [repository migration](#repository-migration-efforts) efforts and
-[co-existence of 2.x/1.x](#co-existence-of-2x1x) are both one-off costs this
+The [repository migration](#cdk-codebase-migration-efforts) efforts and
+co-existence of 2.x/1.x are both one-off costs this
 proposal suggests ways to reduce the chance for merge conflicts across these
 branches.
 
@@ -1201,6 +1201,3 @@ The original text follows:
 > See
 > [discussion](https://github.com/aws/aws-cdk-rfcs/pull/195/files#r460718960)
 > over the RFC PR.
-
-[`constructnode`]:
-  https://github.com/hashicorp/terraform-cdk/blob/5becfbc699180adfe920dec794200bbf56dda0a7/packages/cdktf/lib/terraform-element.ts#L21

text/0324-cdk-construct-hub.md

@@ -258,8 +258,6 @@ detail pages.
      ------------|----------------------------------------------------------------
      `v${major}` | All versions part of this major version stream, and their status
 
-     [SemVer]: https://semver.org/spec/v2.0.0.html
-
      In order to ensure consistency of the contents of the `versions.json`
      object, its content will always be generated from the live inventory of
      objects in S3 (and not incrementally using the update trigger event), and
@@ -280,8 +278,6 @@ detail pages.
    This transformation is backed by the `jsii-rosetta` tool, which is part of
    the [jsii project][jsii], as well as custom code for generating language specific API references.
 
-   [jsii]: https://aws.github.io/jsii
-
    - The **Doc-Gen** functions run asynchronously, and the documentation definition
      eventually becomes available. If the object is not available yet,
      the web UI should present the user with a message inviting them to come

text/0477-policy-validation.md

@@ -95,7 +95,7 @@ Ensure S3 Buckets are encrypted with a KMS CMK (1 occurrences)
 Severity: medium
 
   Occurrences:
-  
+
     - Construct Path: MyStack/MyCustomL3Construct/Bucket
     - Stack Template Path: ./cdk.out/MyStack.template.json
     - Creation Stack:
@@ -121,7 +121,7 @@ Severity: medium
     > Add to construct properties for `cdk-app/MyStack/Bucket`
       `encryption: BucketEncryption.KMS`
 
-  
+
 Validation failed. See above reports for details
 ```
 
@@ -474,7 +474,7 @@ CDK at a larger scale.
 
 ### What is the technical solution (design) of this feature?
 
-See [Appendix A - High level design](#appendix-a-high-level-design).
+See [Appendix A - High level design](#appendix-a---high-level-design).
 
 ### Is this a breaking change?
 
@@ -615,7 +615,7 @@ plugin should conform to.
 
 Zero or more plugins may be added to the CDK application's `App` instance. At
 some point during synthesis (
-see [Appendix B - Implementation details](#appendix-b-implementation-details)
+see [Appendix B - Implementation details](#appendix-b---implementation-details)
 for
 some possibilities) the framework will pass the generated CloudFormation
 template to all the plugins, collect the output