MINOR: replaces non-ASCII dashes with the standard ASCII hyphen

[Parkerhiphop]

Replaces non-ASCII dashes ( – or —) with the standard ASCII hyphen ( - )
for
KAFKA-17019.

[gaurav-narula]

Thanks for PR! I see there are other places where we use the em-dash besides these files. Perhaps consider replacing them as well please?

docs/introduction.html:    Events are organized and durably stored in <strong>topics</strong>. Very simplified, a topic is similar to a folder in a filesystem, and the events are the files in that folder. An example topic name could be "payments". Topics in Kafka are always multi-producer and multi-subscriber: a topic can have zero, one, or many producers that write events to it, as well as zero, one, or many consumers that subscribe to these events. Events in a topic can be read as often as needed—unlike traditional messaging systems, events are not deleted after consumption. Instead, you define for how long Kafka should retain your events through a per-topic configuration setting, after which old events will be discarded. Kafka's performance is effectively constant with respect to data size, so storing data for a long time is perfectly fine.
docs/ops.html:    Replicated topics in a target cluster—sometimes called <em>remote</em> topics—are renamed according to a replication policy. MirrorMaker uses this policy to ensure that events (aka records, messages) from different clusters are not written to the same topic-partition. By default as per <a href="https://github.com/apache/kafka/blob/trunk/connect/mirror-client/src/main/java/org/apache/kafka/connect/mirror/DefaultReplicationPolicy.java">DefaultReplicationPolicy</a>, the names of replicated topics in the target clusters have the format <code>{source}.{source_topic_name}</code>:
docs/ops.html:    In the following example, user Alice—a new member of ACME corporation's InfoSec team—is granted write permissions to all topics whose names start with "acme.infosec.", such as "acme.infosec.telemetry.logins" and "acme.infosec.syslogs.events".
docs/ops.html:  Multi-tenant clusters should generally be configured with <a href="#design_quotas">quotas</a>, which protect against users (tenants) eating up too many cluster resources, such as when they attempt to write or read very high volumes of data, or create requests to brokers at an excessively high rate. This may cause network saturation, monopolize broker resources, and impact other clients—all of which you want to avoid in a shared environment.
docs/ops.html:  <strong>Client quotas:</strong> Kafka supports different types of (per-user principal) client quotas. Because a client's quotas apply irrespective of which topics the client is writing to or reading from, they are a convenient and effective tool to allocate resources in a multi-tenant cluster. <a href="#design_quotascpu">Request rate quotas</a>, for example, help to limit a user's impact on broker CPU usage by limiting the time a broker spends on the <a href="/protocol.html">request handling path</a> for that user, after which throttling kicks in. In many situations, isolating users with request rate quotas has a bigger impact in multi-tenant clusters than setting incoming/outgoing network bandwidth quotas, because excessive broker CPU usage for processing requests reduces the effective bandwidth the broker can serve. Furthermore, administrators can also define quotas on topic operations—such as create, delete, and alter—to prevent Kafka clusters from being overwhelmed by highly concurrent topic operations (see <a href="https://cwiki.apache.org/confluence/x/6DLcC">KIP-599</a> and the quota type <code>controller_mutation_rate</code>).
docs/quickstart.html:            need—even forever.
docs/quickstart.html:            Now that you reached the end of the quickstart, feel free to tear down the Kafka environment—or
streams/src/main/java/org/apache/kafka/streams/kstream/Repartitioned.java:     *                    {@link WindowedStreamPartitioner} will be used—otherwise {@link DefaultStreamPartitioner} will be used
streams/src/main/java/org/apache/kafka/streams/kstream/Repartitioned.java:     *                    {@link WindowedStreamPartitioner} will be used—otherwise {@link DefaultStreamPartitioner} will be used
clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java:    private static final String INIT_TXN_TIMEOUT_MSG = "InitTransactions timed out — " +
clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerNetworkThread.java:     * Process the events—if any—that were produced by the application thread.
clients/src/main/java/org/apache/kafka/clients/consumer/internals/AsyncKafkaConsumer.java:     * Process the events—if any—that were produced by the {@link ConsumerNetworkThread network thread}.
clients/src/main/java/org/apache/kafka/clients/consumer/internals/AbstractFetch.java:     * Here's why this is important—in a production system, a given leader node serves as a leader for many partitions.
clients/src/test/java/org/apache/kafka/clients/producer/KafkaProducerTest.java:            "InitTransactions timed out — " +

[Parkerhiphop]

@gaurav-narula Thanks for the review and for pointing that out!
I have updated the PR to include fixes for all other instances found in the project.
Please review again when you have a chance.

[gaurav-narula]

LGTM. Test failure seems unrelated