Fix #40661: internal error 200612311 when specializing overloaded generic procedure
Fixes #40661 (reported by me).
When a procsym has multiple overloaded generic procdefs and one of them is currently being parsed, generate_specialization_phase2 short-circuits and returns the original generic procdef unchanged (its tokenbuffer is not yet set). The cleanup logic in tcallcandidates.create_candidate_list for unused specializations then tried to extract and free that original generic procdef, which still had an owner, triggering the internal error in tstoreddef.destroy.
Only free the procdef when it is actually a specialization (df_specialization in defoptions). Test in tests/webtbs/tw40661.pp.