boards: rename native64 -> native

[OlegHahm]

Contribution description

This patch renames the current native board into native32 and replaces it with the current native64 board.

The changeset is mostly renaming directories and replacing native64 with native32 within application Makefiles (unless native64) was not supported.

It's only superficially tested so far. Let's see what the CI comes up with.

Testing procedure

Use your favorite RIOT application on native.

[riot-ci]

Murdock results

✔️ PASSED

f079269 test: pkg: special cases for native32 only

Success	Failures	Total	Runtime
10249	0	10249	13m:26s

Artifacts

• Documentation preview

[miri64]

Should we, while maybe more complicated, make the rename to native32 first, make a link to it as native (see e.g. feather-m0-lora for how to link a board variant) and then walk through our normal deprecation cycle for the relinking to native64? Or can we just assume that people want native64 ASAP and that native64 is stable enough by now to not cause any regressions?

[miri64]

(maybe we should even integrate native64 into the release tests first)

[OlegHahm]

I think there is indeed no reason to rush it. Integrating it into the release tests, might be a good idea. But I don't get your proposal for the deprecation cycle. (Do we want to deprecated native 32 bit at all?)

[miri64]

But I don't get your proposal for the deprecation cycle. (Do we want to deprecated native 32 bit at all?)

No, just the fact that native is native32, i.e., have native point to native32 and make a deprecation note, that it will point to native64 2 release cycles later.

[OlegHahm]

Ah, understood. Not sure though whether this is necessary. After all native is most likely not used in production but rather for testing and debugging. It should work reliable, so extending the transition time is a good thing but we should make sure that more people are using the 64 bit variant during this transition time to check for its reliability.