[manuf] Move default perso extensions outside of extension

[pamaury]

Those files are used in the provisioning inputs of the OT repository unconditionally. This means that when the provisioning extension module gets overriden by the manufacturer, references like @provisioning_exts//:default_ft_ext_lib will now point to manufacturer code instead of the "default"/example provisioning code. At best, this can produce a compile error and at worse produce a non-functional perso/rom_ext when building the emulation skus.

This commit moves those default files outside of the extension so that they can be referenced even when overriding the extension.

Context: without this, using the ot-sku repository as a provisioning extension breaks all emulation skus.

[pamaury]

Note: technically, all those @lowrisc_opentitan references are not needed since package is part of lowrisc_opentitan. I kept it since it was present and it at least provided a very easy file to copy-paste to extension, so might be worth keeping?

[cfrantz]

I think this change affects the ML-DSA work by @sasdf and @xorptr; I think change is a move in the right direction: we want the default ML-DSA perso extension to be library code that can be re-used by downstream SKU configs.

[xorptr]

I think this change affects the ML-DSA work by @sasdf and @xorptr; I think change is a move in the right direction: we want the default ML-DSA perso extension to be library code that can be re-used by downstream SKU configs.

I agree. Currently, the downstream code has alias targets that point to build targets with source files that are copies of the upstream default extension code. For ML-DSA default extension alias in the downstream code, I added an alias target that points back to the upstream @lowrisc_opentitan default extension target.

Having this changes would allow removing these alias targets in the downstream code.

[pamaury]

This PR only moves the files so it should be relatively harmless but if you have work in progress and want to avoid rebase conflicts, we can keep this open until all MLDSA changes are done.

[xorptr]

This PR only moves the files so it should be relatively harmless but if you have work in progress and want to avoid rebase conflicts, we can keep this open until all MLDSA changes are done.

I would prefer to merge this after reviews and use it downstream

[AlexJones0]

LGTM after my comments are addressed. Thanks @pamaury.

[pamaury]

I have rebased since there were some recent changes but I tested locally and it works.

[pamaury]

I have tried cherry-picking #30906 to see if it helps with the USB problems.

[pamaury]

CI failures are due to some CI problems with the CW310. All manufacturing tests passed on the CW340 so this should be safe to merge.