update: align multiplatform docs to {} block style

Author: sarahhaggarty

docs/topics/multiplatform/multiplatform-add-dependencies.md

@@ -4,7 +4,7 @@ Every program requires a set of libraries to operate successfully. A Kotlin Mult
 multiplatform libraries that work for all target platforms, platform-specific libraries, and other multiplatform projects.
 
 To add a dependency on a library, update your `build.gradle(.kts)` file in the directory of your project containing shared code. Set a
-dependency of the required [type](gradle-configure-project.md#dependency-types) (for example, `implementation`) in the [`dependencies`](multiplatform-dsl-reference.md#dependencies)
+dependency of the required [type](gradle-configure-project.md#dependency-types) (for example, `implementation`) in the [`dependencies {}`](multiplatform-dsl-reference.md#dependencies)
 block: 
 
 <tabs group="build-script">

docs/topics/multiplatform/multiplatform-android-dependencies.md

@@ -36,7 +36,7 @@ Moving what was a top-level dependency in an Android project to a specific sourc
 might be difficult if the top-level dependency had a non-trivial configuration name. For example, to move
 a `debugImplementation` dependency from the top level of an Android project, you'll need to add an implementation
 dependency to the source set named `androidDebug`. To minimize the effort you have to put in to deal with migration
-problems like this, you can add a `dependencies` block inside the `android` block:
+problems like this, you can add a `dependencies {}` block inside the `android {}` block:
 
 <tabs group="build-script">
 <tab title="Kotlin" group-key="kotlin">
@@ -68,7 +68,7 @@ android {
 Dependencies declared here will be treated exactly the same as dependencies from the top-level block, but declaring them
 this way will also separate Android dependencies visually in your build script and make it less confusing.
 
-Putting dependencies into a standalone `dependencies` block at the end of the script, in a way that is idiomatic to
+Putting dependencies into a standalone `dependencies {}` block at the end of the script, in a way that is idiomatic to
 Android projects, is also supported. However, we strongly recommend **against** doing this because configuring a build
 script with Android dependencies in the top-level block and other target dependencies in each source set is likely to
 cause confusion.

docs/topics/multiplatform/multiplatform-compatibility-guide.md

@@ -22,10 +22,10 @@ with available Gradle, Xcode, and Android Gradle plugin versions:
 
 **What's changed?**
 
-Target accessors auto-generated by Gradle are no longer available inside the `kotlin.targets` block. Use
+Target accessors auto-generated by Gradle are no longer available inside the `kotlin.targets {}` block. Use
 the `findByName("targetName")` method instead.
 
-Note that such accessors are still available in the `kotlin.targets` case, for example, `kotlin.targets.linuxX64`.
+Note that such accessors are still available in the `kotlin.targets {}` case, for example, `kotlin.targets.linuxX64`.
 
 **What's the best practice now?**
 
@@ -66,7 +66,7 @@ kotlin {
 
 **When do the changes take effect?**
 
-In Kotlin 1.7.20, an error is introduced when using target accessors in the `kotlin.targets` block.
+In Kotlin 1.7.20, an error is introduced when using target accessors in the `kotlin.targets {}` block.
 
 For more information, see the [corresponding issue in YouTrack](https://youtrack.jetbrains.com/issue/KT-47047).
 
@@ -367,7 +367,7 @@ load on the Kotlin team. We encourage you to migrate to the `kotlin-multiplatfor
 **What's the best practice now?**
 
 1. Remove the `kotlin-js` Gradle plugin from your project and apply `kotlin-multiplatform` in the `settings.gradle.kts` file
-   if you're using the `pluginManagement` block:
+   if you're using the `pluginManagement {}` block:
 
    <tabs>
    <tab title="kotlin-js">
@@ -412,13 +412,13 @@ load on the Kotlin team. We encourage you to migrate to the `kotlin-multiplatfor
 2. Move your source files from the `main` and `test` folders to the `jsMain` and `jsTest` folders in the same directory.
 3. Adjust dependency declarations:
 
-   * We recommend using the `sourceSets` block and configuring dependencies of respective source sets,
-     `jsMain` for production dependencies and `jsTest` for test dependencies.
+   * We recommend using the `sourceSets {}` block and configuring dependencies of respective source sets,
+     `jsMain {}` for production dependencies and `jsTest {}` for test dependencies.
      See [Adding dependencies](multiplatform-add-dependencies.md) for more details.
    * However, if you want to declare your dependencies in a top-level block,
      change declarations from `api("group:artifact:1.0")` to `add("jsMainApi", "group:artifact:1.0")` and so on.
 
-     > In this case, make sure that the top-level `dependencies` block comes **after** the `kotlin` block. Otherwise, you'll get an error "Configuration not found".
+     > In this case, make sure that the top-level `dependencies {}` block comes **after** the `kotlin {}` block. Otherwise, you'll get an error "Configuration not found".
      >
      {type="note"}
 
@@ -459,7 +459,7 @@ load on the Kotlin team. We encourage you to migrate to the `kotlin-multiplatfor
            // ...
        }
 
-       // Option #1. Declare dependencies in the sourceSets block:
+       // Option #1. Declare dependencies in the sourceSets {} block:
        sourceSets {
            val jsMain by getting {
                dependencies {
@@ -479,7 +479,7 @@ load on the Kotlin team. We encourage you to migrate to the `kotlin-multiplatfor
    </tab>
    </tabs>
 
-4. The DSL provided by the Kotlin Gradle plugin inside the `kotlin` block remains unchanged in most cases. However,
+4. The DSL provided by the Kotlin Gradle plugin inside the `kotlin {}` block remains unchanged in most cases. However,
    if you were referring to low-level Gradle entities, like tasks and configurations, by names, you now need to adjust them,
    usually by adding the `js` prefix. For example, you can find the `browserTest` task under the name `jsBrowserTest`.
 

docs/topics/multiplatform/multiplatform-native-artifacts.md

@@ -25,8 +25,8 @@ artifact with new DSL.
 
 ## Declare binaries
 
-The `kotlinArtifacts` element is the top-level block for artifact configuration in the Gradle build script. Use
-the following kinds of binaries to declare elements of the `kotlinArtifacts` DSL: 
+`kotlinArtifacts {}` is the top-level block for artifact configuration in the Gradle build script. Use
+the following kinds of binaries to declare elements of the `kotlinArtifacts {}` DSL: 
 
 | Factory method | Binary kind                                                                               | Available for                                |
 |----------------|-------------------------------------------------------------------------------------------|----------------------------------------------|