CONTRIBUTING.md: Update markdown emphasising syntax

GitHub supported special markdown syntax for emphasising blocks for some
time. This was however a beta feature, and still is, so it's subject to
changes.

Recently such a change happened: The syntax is different now.

See https://github.com/orgs/community/discussions/16925 for more
information

CONTRIBUTING.md

@@ -26,7 +26,7 @@ This file contains general contributing information, but individual parts also h
 
 This section describes in some detail how changes can be made and proposed with pull requests.
 
-> **Note**
+> [!Note]
 > Be aware that contributing implies licensing those contributions under the terms of [COPYING](./COPYING), an MIT-like license.
 
 0. Set up a local version of Nixpkgs to work with using GitHub and Git
@@ -273,7 +273,7 @@ Once a pull request has been merged into `master`, a backport pull request to th
 
 ### Automatically backporting changes
 
-> **Note**
+> [!Note]
 > You have to be a [Nixpkgs maintainer](./maintainers) to automatically create a backport pull request.
 
 Add the [`backport release-YY.MM` label](https://github.com/NixOS/nixpkgs/labels?q=backport) to the pull request on the `master` branch.
@@ -285,14 +285,14 @@ This can be done on both open or already merged pull requests.
 To manually create a backport pull request, follow [the standard pull request process][pr-create], with these notable differences:
 
 - Use `release-YY.MM` for the base branch, both for the local branch and the pull request.
-  > **Warning**
+  > [!Warning]
   > Do not use the `nixos-YY.MM` branch, that is a branch pointing to the tested release channel commit
 
 - Instead of manually making and committing the changes, use [`git cherry-pick -x`](https://git-scm.com/docs/git-cherry-pick) for each commit from the pull request you'd like to backport.
   Either `git cherry-pick -x <commit>` when the reason for the backport is obvious (such as minor versions, fixes, etc.), otherwise use `git cherry-pick -xe <commit>` to add a reason for the backport to the commit message.
   Here is [an example](https://github.com/nixos/nixpkgs/commit/5688c39af5a6c5f3d646343443683da880eaefb8) of this.
 
-  > **Warning**
+  > [!Warning]
   > Ensure the commits exists on the master branch.
   > In the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
 
@@ -305,7 +305,7 @@ To manually create a backport pull request, follow [the standard pull request pr
 ## How to review pull requests
 [pr-review]: #how-to-review-pull-requests
 
-> **Warning**
+> [!Warning]
 > The following section is a draft, and the policy for reviewing is still being discussed in issues such as [#11166](https://github.com/NixOS/nixpkgs/issues/11166) and [#20836](https://github.com/NixOS/nixpkgs/issues/20836).
 
 The Nixpkgs project receives a fairly high number of contributions via GitHub pull requests. Reviewing and approving these is an important task and a way to contribute to the project.
@@ -384,7 +384,7 @@ By keeping the `staging-next` branch separate from `staging`, this batching does
 In order for the `staging` and `staging-next` branches to be up-to-date with the latest commits on `master`, there are regular _automated_ merges from `master` into `staging-next` and `staging`.
 This is implemented using GitHub workflows [here](.github/workflows/periodic-merge-6h.yml) and [here](.github/workflows/periodic-merge-24h.yml).
 
-> **Note**
+> [!Note]
 > Changes must be sufficiently tested before being merged into any branch.
 > Hydra builds should not be used as testing platform.
 

doc/README.md

@@ -48,7 +48,7 @@ It uses the widely compatible [header attributes](https://github.com/jgm/commonm
 ## Syntax {#sec-contributing-markup}
 ```
 
-> **Note**
+> [!Note]
 > NixOS option documentation does not support headings in general.
 
 #### Inline Anchors

pkgs/README.md

@@ -470,7 +470,7 @@ Preferred source hash type is sha256. There are several ways to get it.
 
    in the package expression, attempt build and extract correct hash from error messages.
 
-   > **Warning**
+   > [!Warning]
    > You must use one of these four fake hashes and not some arbitrarily-chosen hash.
    > See [here][secure-hashes]