TLDR: use #1, perhaps with Argon2 at minimal security level as the KDF.
The three options work, and are secure if Argon2 matches it's design goals, which we have no reason to doubt, under the reasonable assumption that even with the strengthening given by Argon2, the choice of password makes a 128-bit security level acceptable.
I do not recommend to "Use Argon2 twice, with different associated data" (#3) if both uses must be performed in the same application (e.g. one output is used to verify the password and the other as key to AES-GCM). That's because two invocations of Argon2 doubles the execution time, or reduces the achievable security by 1 bit for a given execution time. If we can afford that doubling of computational cost, from a security standpoint when the password is the weak spot, we are better with a single Argon2 computation using twice as much resources, as in #1 and #2.
The "split" (#2) option is initially simpler, but (as noted in comment) the Argon2 RFC security claim limits security to $2^{128}$ Blake2b invocations when one of the output segment is known (but the password is usually considered a weaker spot even with the strengthening given by Argon2). Also, #2 can't be safely extended unless we spare enough tag for extension (which can be per the method of #1): we want that the extensions remain secure under the assumption the other output values are disclosed, thus need spare Argon2 tag, but extending the size of the tag breaks compatibility, because in Argon2 the tag length influences the whole tag value.
The "KDF" (#1) option has the advantage of clean extensibility, e.g. to a new type of key, like an RSA private key. It's also gives a better assurance than #2 for independence of the outputs. That's limited by the KDF security; the maximum entropy in the tag output by Argon2, which is at least nearly 256 bits; and the weakness of the password of course. In principle #1 is even slightly better from the standpoint of independence of the outputs if there in a lot of entropy in the password input; but then we wouldn't need Argon2.
I recommend that the tag size for #1, or the spare tag size for #2, is set to at least 32 bytes (256-bit), because we can at almost no cost.
In #1 we need a KDF. It can be a standard one (of the fast breed), including Argon2 with minimal cost parameters.
what general property I am after
A purposely-slow password-to-hash/key derivation function is often designated password hashing (function), or password-based key derivation function (which is more descriptive but has a namespace collision with the technically poor and obsolete PBKDF2 or it's ancestor PKDF1), or key stretching (function), sometime entropy stretching (function).
Prepending a memory hard prefix, as in memory-hard (password-based key derivation) function, adds that the transformation mobilizes the size and bandwidth of memory, proportionally to the number of instances running in parallel for different key/password input, which greatly helps against password cracking. That concept was pioneered to some degree by bcrypt, extended and formalized by Scrypt (which remains a decent choice for password-to-hash/key transformation), and polished in Argon2.
As for the property that the output can be safely split (for #2), I know no specific name. It follows from the property that the output remains computationally indistinguishable from random with both less work than finding the key/password by brute force, and less work than some claimed security level for distinguishing the output from random. I know no more specific name. It's a desired property of a KDF.
Revision: I significantly revised the answer following the comment below, to take into account the quoted security claim of Argon2. And as a consequence I downgraded #2. Independently, I added that it's safely extensible only if there is spare tag for that. Also I simplified and generalized the property in the last paragraph, my original wording (in the above comment) was unnecessarily complicated.
