There's really no good way to do this.
The first problem is that story points and velocity are a relative measure that is highly sensitive to changes. Whether it's a team member taking a day off, learning something new about the work being done, process changes, permanent addition or removal of staff to the team, and other factors can all influence the team's velocity.
In this particular situation, the fact that people are not 100% available is a potential problem. Most Agile methodologies are built around a stable, long-lived team. Although people may take some time off from time to time, the expectation is that the people are fully dedicated to the effort. The idea of a stable team also leads to helping to compute the cost, since the paying customer funds the team for a number of iterations. Depending on the environment, they could even fund one iteration at a time, ending the effort once the cost of performing another iteration exceeds the maximum value that can be delivered or earned by maintaining the team and product.
In reality, though, it can be a desire to attempt to look ahead and get a rough idea of how long an effort will take and how much it will cost for the team to execute over that duration. It's important to realize that this type of forecasting is highly speculative since there are so many factors that can affect the performance of the team. In addition, doing work changes the work that must be done. Over time, the team may discover new work that is important as well as learning that some things they planned on doing are no longer necessary. The state of the backlog of work fluctuates frequently as stakeholders interact with working software.
If you're in a position where you still want to forecast, one good technique is the application of Yesterday's Weather. Yesterday's Weather is using the performance of the previous iteration to forecast the team's performance for the upcoming iteration. Although some people take the average of the past few iterations, others recommend only using the most recent iteration. For forecasting the next iteration, it is probably better to only use the most recent iteration, unless that one iteration is very atypical. For long-term forecasting, a rolling average of 3-5 iterations would probably be better to remove noise.
In this chart, I've added the ratio of story points to effort spent. If you have a stable team, this isn't necessary. However, if you have an unstable team and are putting in various amounts of effort, this may be a factor that you want to consider.
If the backlog started with 200 story points, you've completed 78 over 4 iterations. That means you have 122 story points left, assuming that you haven't added or removed anything from the backlog.
Over the course of the 4 iterations, you've had an average of about 20.75 people-days per iteration. You also complete about 0.94 points per person day. If you can project your capacity forward, you may be able to use this to figure out your range. It is probably best to compute a range using best-case and worst-case values, along with averages. Iteration 2 had the worst completion, with only 16 story points and 0.8 points per person-day. Iteration 3 was the best completion, with 24 story points and 1.04 points per person-day. It also seems like the historical data trends between 19 and 23 person-days.
Using this data, you can compute a number of possibilities. Maybe you trend closer to 19 person-days and 0.8 points per person-day, with an output of 15-16 story points, which would result in about 8 iterations left. Maybe you tend closer to 24 story points and 1.04 points per person-day, for about 24-25 points for about 5 iterations left. It could be somewhere closer to the average, with the team completing 18-19 points per iteration for 7 iterations left.
If you wanted to, you could get into more statistical analysis, but I'm not sure that kind of effort is needed in most cases. Just based on some quick, back-of-the-envelope calculations, I would present an estimate of about 5-8 iterations, with 7-8 being the most likely. Of course, this assumes no significant changes to the backlog of work, the team, and the team's way of working - any of these would likely have a measurable impact.