Change and extend Cmm import syntax to support symbols from external DSOs

As part of trying to add full support for dynamic linking on windows #27162, we run into the problem that on windows we have to be much more precise than on other platforms about which symbols refer to things from the same DSO (i.e. a .dll) and which refer to symbols from external DSOs.

This MR makes a number of changes and extensions to the cmm import syntax.

Currently we have:

import foo;
import CLOSURE foo; -- same but import of data rather than function

which in principle currently means to expect the symbol foo from an external DSO.

This MR changes the interpretation of the existing syntax to expect the symbol be found within the same DSO. And then we also add new syntax for the external case:

import extern foo;
import extern DATA foo; -- same but import of data rather than code

And while we're tidying things up, we add DATA as the new name for CLOSURE since it more accurately reflects the semantics. We keep CLOSURE as an alias.

And for completeness, also add support for "package" imports using DATA too.

This adds two new reserved words in cmm: extern and DATA.

Now in practice, all of this makes no difference whatsoever on current supported platforms. The labelDynamic helper simply says True irrespective for all labels declared via cmm import (on non-windows platforms). Perhaps it should make distinctions, but it does not.

On Windows however this does make a difference and we have to get it right. We need to be able to specify local or external symbols. Having the default be local seems the best default. It matches C compilers, and is the most common.

I have not found any uses of cmm import outside of RTS cmm code. It could in principle be used in cmm code in libraries that want to access RTS symbols, but weirdly there does not appear to be any. Or perhaps it's using the implicit name declaration thing in cmm foreign calls.