Two possible approaches explored here: shrink /dev/sda2 or nuke /dev/sda1's partition (while leaving its data in tact).
I'm sure there are other options other than these two. I'm just pointing out some approaches.
Why do you want to move the primary partition into the extended partition?
I'm going to guess that you're concerned with a limit: The traditional limits on an MBR is 4 partitions. If the /dev/sda3 was moved into an extended partition, then you would accomplish getting around that limit.
However, where are you planning to place the Fedora partition? Specifically, what are going to be the "Start" value and the "End" value? You also have another issue to take care of, which is the matter of having enough space available.
From the fdisk report, /dev/sda4 is your Extended partition, which starts at 85628928 which is 2048 before the start of /dev/sda5. So, what this shows is that there is a bit of space at the start of the Extended partition before the first "logical drive" that is inside the Extended partition. Now, your /dev/sda3 starts at 84604928 which is exactly one sector after /dev/sda2 ends at 84604927. So, there is no free space before /dev/sda3 to insert the start of the Extended partition.
This means you basically have two choices: moving the contents of the /dev/sda3 partition, or shrinking /dev/sda2 (by at least 2048) so that /dev/sda2 ends sooner. Simply shrinking is probably a safer task than trying to re-locate a partition. Those are the really dangerous parts of the process. If you can shrink /dev/sda2, then you can adjust the starting sector of the extended partition, which is rather safe to do with some software. (OpenBSD's fdisk is the best I've seen with modern software: Ranish Partition Manager was also great.)
From the picture, it looks like you have "Not Allocated" space after the extended partition.
Actually... there may be a much easier way to handle all this. Do you use the /dev/sda1? Or is it some sort of System Recovery partition that you don't actually use?
If you don't actually use /dev/sda1, you could do this:
A) Use OpenBSD fdisk (I'm just rather familiar with this software option.)
B) Edit partition 0 (assuming that is the one that starts at 2048, ends at 718847, and is type ID 7).
Note: block sizes might be reported differently? If so, compensate with the different numbers, as appropriate.
C) Make the following changes to the Partition 0:
Start: change from 2048 to 0
End: Change from 718847 to 0
Type/ID : Change from 07 to 00
There, you now have a free spot on the MBR.
You can now add a partition, and have it start after 883879935, and use up that 44.29 GB you have at the end of the drive.
Your NTFS data will just continue to sit on the disk at 2048. If you ever felt the need to boot from it again, you could edit the MBR to change the partition to start back on 2048, end on 718847, and use Type/ID 07 again.
There's really no limit that you can only have partitions (one being the "extended") on the drive. The common limit is just that you can only have 4 such partitions defined by the MBR, so you can only have that many available/active at a single time. But you can flip back and forth at will.
I've done such shenanigans successfully before. Note, however, that some software might do some weird things and try to write to space that isn't in a partition. I'd be particularly wary about Hibernation support (is this a laptop?). Also, my experience with Microsoft System Center Data Protection Manager (backup software) suggests that it stores data in some way other than using a filesystem volume within a defined partition. One nice thing about OpenBSD's fdisk is that you can just modify the boot records, which are changes that can be reverted with enough care. Back in the days when I used MS-DOS more often, Microsoft's FDISK would kindly destroy the first 512 bytes (or was it 2048 bytes?) of data in a partition. If such changes are made to a filesystem volume, that essentially causes data loss which usually renders the entire filesystem volume to be unusable. So the ability to do some tasks safely may depend on what software you are using (as well as how well you know what you're doing, and how careful you are). I wouldn't recommend playing around with any sort of drive resizing/moving, or partition deleting (while trying to leave the filesystem volume in tact) if I didn't already have all important data sufficiently backed up (preferably on a different drive).
One thing you may want to do is to COPY (not MOVE) your existing /dev/sda3 partition. You've got enough free space after /dev/sda7 to store a copy (or even multiple copies). In theory, this could be done with dd (using appropriate values for things like skip=). But if you write to unpartitioned space, you're generally going to need to be extremely careful that you don't let the space be used (written to) by multiple pieces of software. If you're not meticulously keeping track of numbers, you'll probably lose it. (For pretty much this whole post, I'm just writing about what is rather possible. For important data, the only approach that is suitably recommendable is to do a proper backup that saves all important data from everyone on the whole drive.)
I confirm Rod Smith's answer to a question from the comments: Linux systems can boot from extended partitions.