purescript / purescript

* Add re-exports to Language.PureScript.CoreFn.Module

We need to make the `ExportSource` from
`Language.PureScript.AST.Declarations.ReExportRef` available during code-gen.
This requires adding it to `Module`.

We don't actually do the work of adding the data in this commit, we merely add
the field, update the JSON codecs, appease the compiler, and add a test for
parsing the new field.

* Add source of re-export to the module

Now that we have a field for them, we add the re-exports to the module so they
show up as both imported modules and exported members during code-gen.

* Generate imports for re-exports

Now that we're threading the necessary information down to `moduleToJs`, we can
use it to generate the imports we need to later re-export.

* Add re-exports to the generated code

We build up the key/value pairs for the re-exports and append them to the rest
of the exports.

This broke bundling and required allowing `<module name>.<member name>` in
addition to `$foreign.<member name>`. This is the only place where I'm unsure of
my changes.

* Handle bracket notation for re-exports while bundling

In the last commit, we handled the case of member access using dot notation, but
the passing tests were a fluke of caching. Now both cases are handled and tests
are passing.

* Add CitizenNet and my CitizenNet account to CONTRIBUTORS.md

I have a separate account that I use for work and prefer to include this in
addition to my personal acccount to differentiate who owns the copyright for
what work.

I also add my employer to the list of companies holding copyright.

* Handle `Language.PureScript.CoreFn.exportToCoreFn` cases explicitly

Previously, it was possible to forget to handle new constructors added to
`DeclarationRef`. Now we handle them explicitly thus eliminating this potential
source of bugs.

* Test re-exports appear in generated code

As suggested by @hdgarrood in
#3883 (review),
we use the FFI to import a re-exported value.

Module `A` defines a value `a`, module `B` re-exports `A`, and module `Main`
does a foreign import of `a` via `B`. Logging the imported value proves that
the re-export chain was successful.

* Add more conditions to re-export test

We tested that the value defined in one module could be re-exported and then
imported via FFI. Now, we test that:

1. a re-exported module doesn't cause a name clash with any data constructors
defined in the re-exporting module

2. a value, `a`, defined in a module, `A`, may be re-exported from another
module, `B`, and again re-exported from a third module, `C`, which imported `a`
from `B`.

* Have test module export data constructor in addition to re-export

I forgot to export the data constructor `A`. I had visually inspected the
generated code and saw that the names didn't conflict. However, it's better to
have the test make this assurance.