[fix] untitle some admonition blockquotes

A workaround to stop the shouting in #1156

Author: MattDodsonEnglish

src/data/markdown/translated-guides/en/01 Get started/03 Running k6.md

@@ -182,7 +182,9 @@ For advanced ramping, you can use [scenarios](/using-k6/scenarios) and the `ramp
 
 ## Execution modes
 
-<Blockquote mod="note" title="Portability is a major design goal of k6">
+<Blockquote mod="note" title="">
+
+**Portability is a major design goal of k6.**
 
 You can run the same test in different modes with minimal changes.
 

src/data/markdown/translated-guides/en/02 Using k6/05 k6 Options/02 Reference.md

@@ -944,7 +944,9 @@ $ k6 run --out influxdb=http://localhost:8086/k6 script.js
 
 The maximum number of requests to make per second, in total across all VUs. Available in `k6 run` and `k6 cloud` commands.
 
-<Blockquote mod="attention" title="This option is discouraged">
+<Blockquote mod="attention" title="">
+
+**This option is discouraged.""
 
 The `--rps` option has caveats and is difficult to use correctly.
 
@@ -1154,7 +1156,9 @@ Add/override an [environment variable](/using-k6/environment-variables) with `VA
 
 To make the system environment variables available in the k6 script via `__ENV`, use the [`--include-system-env-vars` option](#include-system-env-vars).
 
-<Blockquote mod="note" title="The `-e` flag does not configure options">
+<Blockquote mod="note" title="">
+
+**The `-e` flag does not configure options.**
 
 This flag just provides variables to the script, which the script can use or ignore.
 For example, `-e K6_ITERATIONS=120` does _not_ configure the script iterations.

src/data/markdown/translated-guides/en/02 Using k6/06 Test lifecycle.md

@@ -11,7 +11,9 @@ a script always runs through these stages in the same order:
 3. VU code runs in the `default` or scenario function, running for as long and as many times as the `options` define. **Required**. 
 4. The `teardown` function runs, postprocessing data and closing the test environment. _Optional._ 
 
-<Blockquote mod="note" title="Lifecycle functions">
+<Blockquote mod="note" title="">
+
+**Lifecycle functions**
 
 Except for init code, each stage occurs in a _lifecycle function_,
 a function called in a specific sequence in the k6 runtime.

src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/01 Executors/05 constant-arrival-rate.md

@@ -16,7 +16,9 @@ useful for a more accurate representation of RPS, for example.
 For explanations about how this executor works, refer to [Open and Closed models](/using-k6/scenarios/concepts/open-vs-closed)
 and [Arrival-rate VU allocation](/using-k6/scenarios/concepts/arrival-rate-vu-allocation).
 
-<Blockquote mod="Note" title="Iteration starts are spaced fractionally">
+<Blockquote mod="Note" title="">
+
+**Iteration starts are spaced fractionally.**
 
 Iterations **do not** start at exactly the same time.
 At a `rate` of `10` with a `timeUnit` of `1s`, each iteration starts about every tenth of a second (that is, each 100ms).
@@ -41,7 +43,9 @@ this executor has the following options:
 When you want to maintain a constant number of iterations without being affected by the
 performance of the system under test.
 
-<Blockquote mod="note" title="Don't put sleep at the end of an iteration">
+<Blockquote mod="note" title="">
+
+**Don't put sleep at the end of an iteration.**
 
 The arrival-rate executors already pace the iteration rate through the `rate` and `timeUnit` properties.
 So it's unnecessary to use a `sleep()` function at the end of the VU code.

src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/01 Executors/06 ramping-arrival-rate.md

@@ -12,7 +12,9 @@ k6 will attempt to dynamically change the number of VUs to achieve the configure
 For explanations about how this executor works, refer to [Open and Closed models](/using-k6/scenarios/concepts/open-vs-closed)
 and [Arrival-rate VU allocation](/using-k6/scenarios/concepts/arrival-rate-vu-allocation).
 
-<Blockquote mod="Note" title="Iteration starts are spaced fractionally">
+<Blockquote mod="Note" title="">
+
+**Iteration starts are spaced fractionally.**
 
 Iterations **do not** start at exactly the same time.
 At a `rate` of `10` with a `timeUnit` of `1s`, each iteration starts about every tenth of a second (that is, each 100ms).
@@ -37,7 +39,9 @@ this executor has the following options:
 If you need your tests to not be affected by the system-under-test's performance, and
 would like to ramp the number of iterations up or down during specific periods of time.
 
-<Blockquote mod="note" title="Don't put sleep at the end of an iteration">
+<Blockquote mod="note" title="">
+
+**Don't put sleep at the end of an iteration.**
 
 The arrival-rate executors already pace the iteration rate through the `rate` and `timeUnit` properties.
 It's unnecessary to use a `sleep()` function at the end of the VU code.

src/data/markdown/translated-guides/en/08 Testing Guides/01 API load testing.md

@@ -91,7 +91,7 @@ The test load configures the traffic generated by the test. k6 provides two broa
 - Through _requests per second_, to simulate raw, real-world throughput
 
 
-<Blockquote mod="note" title="Sleep when testing APIs">
+<Blockquote mod="note" title="">
 
 Generally, your load tests should add [sleep time](https://k6.io/docs/javascript-api/k6/sleep/).
 Sleep time helps control the load generator and better simulates the traffic patterns of human users.