Evaluating a hashing function used to create secure API key
No, it isn't secure.

Inventing your own hashing algorithms is a horrible idea. When doing password hashing, use something invented by cryptographers that was made for password hashing, e.g. bcrypt. Because I'm not a cryptographer either, I can't give you a full explanation why your code is insecure. In short, the mistake you made was hashing each character of the password on its own. A few things I spotted:


The final output has a length proportional to the length of the password. This can be abused for denial-of-service attacks or to limit the search space when cracking via brute force.
In your final hash, the letters of $salt2 will occur more often. Therefore the resulting hash isn't evenly distributed over the output domain.
Same letters in the password obviously have the same hash. But as that is directly reflected in the output, this can be used as an attack vector (even if I don't know which letter is repeated). 
It is not possible to extract the salt(s) from a given hash because you shuffle the string – therefore it is impossible to say whether a given password is the same as the hashed password (we can only check whether the lengths are the same). This makes your hash function unsuitable for authentication – but for what are you using it then? For an API key, an unique random number that does not depend on user input would be better.
…


Your code also uses, but does not define the $salt variable – it assigns $salt1 and $salt2. The $salt1 variable isn't used anywhere.

Secure password hashing is only difficult if you try to use a home-brewed solution. I outlined suggested authentication workflows in another answer which includes a list of recommended password hashing solutions (neither your code, SHA-512, nor MD5 is on that list, don't use them for passwords).