Add x86-64_full capability

[DL6ER]

Thank you for your contribution to the Pi-hole Community!

Please read the comments below to help us consider your Pull Request.

We are all volunteers and completing the process outlined will help us review your commits quicker.

Please make sure you

1. Base your code and PRs against the repositories developmental branch.
2. Sign Off all commits as we enforce the DCO for all contributions
3. Sign all your commits as they must have verified signatures
4. File a pull request for any change that requires changes to our documentation at our documentation repo

---

What does this PR aim to accomplish?:

Allow building a (nearly) all-options build of dnsmasq

How does this PR accomplish the above?:

Add remaining dependencies. We skip i18n and ubus as the former strongly depends on the user's system and makes nearly no difference code-wise (one macro is re-defined). ubus is only natively available on OpenWRT systems and not easily installable on any other distributions.

The x86_64 container needs more time for building now as it has an additional stage to build such a full dnsmasq build in addition to the regular build. Both binaries are tested.

Link documentation PRs if any are needed to support this PR:

None

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code and I have tested my changes.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)
6. I have checked that another pull request for this purpose does not exist.
7. I have considered, and confirmed that this submission will be valuable to others.
8. I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
9. I give this submission freely, and claim no ownership to its content.

---

• I have read the above and my PR is ready for review. Check this box to confirm

[DL6ER]

The action on FTL's branch special/CI_development is expected to fail the _full workflow path as this will only work once these containers are tagged and pushed.

[yubiuser]

Shouldn't we move all the extra stuff that is needed only for the all-in below the FROM builder AS all-in-compilation line?

So it won't be included in the pushed "normal" build image?

__

I would also add a new "tester-all-in" step to be able to push an "all-in" image without the test remains.

[DL6ER]

Creating two containers (one large one, another one even larger) doesn't seem to make too much sense when we can just live with one (the even larger). It does not only save (total) space but also eases maintenance as we'd otherwise have two mostly identical Dockerfile where we need to update/change things.

The separation of the builder (#57) should already cover this - or did I misinterpret something? We are pushing the builder and not the all-in-compliation target

[yubiuser]

I think we should also test the "all-in" during image creation and not only during the builds in the FTL repo. Currently, our ftl-build.yml only build two targtes, builder and tester.
You can see it in the latest run, the "all-in" is not tested: https://github.com/pi-hole/docker-base-images/actions/runs/3443550395/jobs/5745202463

You would need to add a section like

      -
        name: Build all-in
        uses: docker/build-push-action@v3
        with:
          context: ftl-build/x86_64_full/.
          push: false
          target: all-in-compilation
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}