Deprecated functionality or legacy versions are probably the only viable route for you if you need to use the same keypair for anything else, and want to avoid doing some extra work. If you're using a unique keypair here, then the minimal-extra-work version is to simply treat the private key as the public key and vice versa, and using the public key, encrypt the hash in PKCS#1 format. The verification side needs to decrypt the hash and then verify it directly, rather than using any built-in verify function. Presumably you already have code to do this, so it shouldn't be that much of a change.
If you do have to re-use that key pair for anything else, and don't want to use a deprecated function or pre-3.x version, then you'll have to fake to OpenSSL which key is the public vs. the private, and do the above operation again passing the actually-the-private-key as the public key that you're encrypting to. This may require modifying the binary blob representing the keys.
Another variant that requires some work on your part is to sign with the private key normally, then modify the signature blob to remove the hash algorithm and make the blob look like private key encryption instead. You'd need to be able to pick apart, modify, and re-pack the PKCS#1 format, but that should be possible.
Obviously, none of these options are a good idea. Which one is least bad will depend on factors such as how much you trust your (or hopefully, some library's) ability to modify the cryptographic data formats, how important it is to be on the latest version and not using a deprecated function, and so on.
RSA signing without including the hash function is unsafe, unless the signer can guarantee that the verifier will only use one known function (and even that is unsafe, because that means the only allowed hash function will probably some day be deprecated due to weaknesses). OpenSSL has historically been quite cavalier about including unsafe functionality, but frankly, removing this one doesn't seem like a problem to me. People get public-key cryptography wrong constantly, and the API pretending like this is a reasonable thing to ever do doesn't help with that.
The problem is that the IEC standard is, in a word, terrible (based on what you wrote here; it apparently costs hundreds just to read it??) and needs to be updated to use standard cryptographic operations and formats. (Do I dare ask what hash function it wants you to use?) I realize this isn't something you personally can fix but maybe you can yell atwrite a strongly worded letter to the standards committee about it.
