Can I use this to save time when doubling the iterations?
Yes, per your own tests. Note that you actually need to parallelize it, if you were using a language/compiler that calculated the first pbkdf2, and after it finishes the second pbkdf2, you would not get that timing improvement.
So the question is, is that last combined key (100k + 100k) as strong as traditionally created key with 200k iterations?
This is an interesting question.
First of all, the two components of the final password hash depend on the same password, so an attacker could not reuse half an output for another iteration (this is generally not possible since the goal of the iterations is precisely that the computation is not parallelizable), so we are fine on this front.
Then, we shall take into account you half the time you need for computing one global password hash, but so does the attacker. However, the attacker already has a parallelizable problem (trying many passwords). So, if an attacker needs half the time, but also computes half the passwords (because when they are now using two cores per password instead of one), you would end up even.
Things get more complicated, though, as an attacker would be unlikely to be using CPU cores for password bruteforcing (with the above result) but GPU cracking. In that case, computing two PBKDF2 for the same password (albeit different salts) may be a simpler calculation than two PBKDF2 for different passwords. Since the salt is only used on the first round of the multiple per-block iterations, that does seem to be the case (but I'm no GPU programmer, plus there may be differences between implementations).
So, I would conclude that computing two 100k PBKDF2 is not stronger than one 200k PBKDF2, and probably somewhat weaker.
On the other hand, the attacker would probably already have code for in-parallel bruteforcing PBKDF2 (likely written by others), whereas needing to adapt it for your custom setup, and the final combining of the two pieces would require some costly human effort (that is only to be paid once, though), which might offset the previous advantage.
should I use HKDF to combine the keys?
I don't think it wil matter much which kind of (cryptographic) function you use for that final combination, but HKDF seems a reasonable option.