For some reason Microsoft envisioned that nobody should be able to add multiple contacts to a lead and have those automatically moved to accounts and when a lead is qualified.
Mayby it works in their mind, but I know for a fact a lot of people do not work with leads as Microsoft has envisioned and desperately need a way to have multiple contacts and have these moved to accounts upon qualification.

The good news is, this can be done by creating a C# plugin.
The only bad news would be if you do not understand how writing and implementing plugins work and do not want to put time into learning this, then you're going to have a bad time.
If you want to manage CRM Dynamics and make use of all of the possibilities, I highly recommend you learn.
Otherwise I would recommend you find a partner to help you implement this or find click2deploy solution online.

As previously mentioned, to achieve this. You need to create a C# plugin and register is with a registration tool. I use the one in XRMToolbox, works fine for me as I never got the official Microsoft one working anyway...
There is no way achieve this solution with Javascript coding, because nothing in Javascript for CRM Dynamics triggers on the Create command in the background like a plugin does.
You could use it with the onLoad or onSave command, but you have to realize that this requires that the users NEED to open the account record before it even processes the contacts.

I'm not going too in depth about how to write a C# plugin from scratch, there are enough guides online that show you the basics so you can get a working connection.
I'm only gonna cover the steps taken to achieve this solution so you have a better understanding on how this works and why it was written this way.

First off, there are prerequisites for this solution to work.

1. The Contact entity must contain the originatingleadid field
2. Your lead entity must contain a Contacts subgrid in the form and users must be able to create new users from there
3. The Account entity must contain the originatingleadid field

The originatingleadid field in the contact entity will always be prefilled with the lead record if the user created the contact through the subgrid
The originatingleadid field in the account entity will always be prefilled with the lead record the moment the lead gets qualified and the account record gets created
This is why the contact subgrid must be there in the lead form, but it kind of speaks for itself that you should add this, because how else are you going to add multiple contacts? :)

Because the originatingleadid field in the account entity gets populated during creation, it makes all the more sense for the plugin to run on the Create command for that entity.

Now lets go through the code piece by piece
You can find the code here so you can browse along while reading this: https://github.com/MoebiusZero/LeadMultiContacts

Step 1: Get the GUID of the account that just got created
This GUID is required because, how else is the code going to assign the contact to the right account? :)

Step 2: Check if the Account comes from a qualified lead
This hecks if the field contains data.
Because the field is always automatically populated upon qualification, it's a good check to start with. If the Account was created directly in the entity, then the field would be empty and the code would just stop here.

Step 3: Get the GUID of the Lead record
This will get the GUID of the lead that's filled in the originatingleadid field. Because the GUID will the same in as the originatingleadid field in the contact, it's therefore a great value to compare with in the code.

Step 4: Configure the filter to get all the contacts that were part of that lead
With the GUID of the lead stored in a variable in step 3, the code will create a filter for the contacts entity with the GUID as the filter.
It's like using the Advanced search in CRM in code form:
In Contacts look in field originatingleadid equals GUID

Step 4: For each found contact, fill the parentcustomerid field with the GUID
First the code will do a RetrieveMultiple based on the filter created in step 4.
It will then parse each found contact and fill the parentcustomerid field with the GUID from the newly created account from part 1 in the contact.


And that's it! During creation of the account, all the contacts get found and assigned this way.
I've added some logging for myself just to check if it finds the right account, contacts and lead and if they get assigned properly.
If you do not require this logging, you can remove the tracingService.Trace lines for each part.