We had a similar challenge. Our approach was to generate a dynamic procedure. This procedure would need to be defined as "READS SQL DATA".
It can't do any looping (or other "Imperative Logic as defined in the SQLScript reference) - simply your CALL statements to your other procedures, which must all also be defined as "READS SQL DATA". The procedure also can't update any database objects (do inserts/updates/deletes, etc.).
If you can meet all these restrictions, then the optimizer, as I understand it, should be able to parallelize the call statements, assuming that it doesn't find any conflicts that would cause it to serialize the requests. There's no mechanism to explicitly execute statements in parallel.