feat: increase number of constructors

[tobiasgrosser]

Read this section before submitting

• Ensure your PR follows the External Contribution Guidelines.
• Please make sure the PR has excellent documentation and tests. If we label it missing documentation or missing tests then it needs fixing!
• Include the link to your RFC or bug issue in the description.
• If the issue does not already have approval from a developer, submit the PR as draft.
• The PR title/description will become the commit message. Keep it up-to-date as the PR evolves.
• For feat/fix PRs, the first paragraph starting with "This PR" must be present and will become a
  changelog entry unless the PR is labeled with no-changelog. If the PR does not have this label,
  it must instead be categorized with one of the changelog-* labels (which will be done by a
  reviewer for external PRs).
• A toolchain of the form leanprover/lean4-pr-releases:pr-release-NNNN for Linux and M-series Macs will be generated upon build. To generate binaries for Windows and Intel-based Macs as well, write a comment containing release-ci on its own line.
• If you rebase your PR onto nightly-with-mathlib then CI will test Mathlib against your PR.
• You can manage the awaiting-review, awaiting-author, and WIP labels yourself, by writing a comment containing one of these labels on its own line.
• Remove this section, up to and including the --- before submitting.

---

This PR <short changelog summary for feat/fix, see above>.

Closes <RFC or bug issue number fixed by this PR, if any>

[Rob23oba]

You need to be really careful here and especially with set_next and get_next in object.cpp which rely on the precise bit pattern here:
Lean relies on the fact that on all supported platforms, virtual addresses are only 48 bit (that is, the two uppermost bytes of a valid address are always zeroed out). The way this is used is that the first/lower 48 bits of this struct are used for the address while m_other and m_tag are kept since they store important information about what kind of object this is and for constructor objects, how many fields there are.
Now with this change, 4 bits of tag information are lost and, worse, it's the lower bits the allow you to distinguish between the different kinds of objects! Now still, we surely don't need to preserve all 12 bits of tag, really, 4 or 8 bits are enough, but then we probably need it to be the higher bits instead of the lower bits so e.g. 0xF30, 0xF40, ..., 0xFF0 for the special ones.
This idea and others will definitely need some adjustments in set_next and lean_del_core though to make work. And then of course, the question is how much the "misalignment" of m_tag will affect performance (3 instructions instead of 1 for lean_ptr_tag).