feat: remove section about treating v4 as a default

Discussion in #3 showed that there is general agreement for only
supporting the v4 algorithm.

However, there are concerns that, if we design an API that promotes one
algorithm as the default, this assumption might not hold in the future.
In order to provide a more future-proof API we may therefore only
support certain algorithms, but will likely not treat any of the
supported algorithms in a speacial way.

Author: ctavan

README.md

@@ -127,18 +127,6 @@ implementations have led to
 It is for this reason that this spec mandates that any random numbers used come from a
 "cryptographically secure" source, thereby (hopefully) avoiding such issues.
 
-### Why does the standard library API treat `v4` UUIDs as a default?
-
-An analysis of popular Open Source projects that were using `v1` UUIDs has shown that the majority
-of identified projects did not have a compelling reason for using `v1` UUIDs, and with education
-were willing to migrate to `v4` UUIDs.
-
-We have reached out to the developers of the 6 most popular (based on watch count) actively
-maintained GitHub projects where this was the case and all of them accepted our pull requests.
-
-Please refer to [analysis/README.md](./analysis/README.md#accidental-v1-usage) for more
-information.
-
 ### But aren't v1 UUIDs better because they are guaranteed to be unique?
 
 As an oversimplification, `v1` UUIDs consist of two parts: A high-precision `timestamp` and a