custom-set: change stub to make it compile.

[rbasso]

This PR makes small changes to allow the stub solution to build and also compile the test suite.

The ability to run the tests with the stub solution is useful mainly for two reasons:

• It allows us to assert that the stub solution is "correct".
• It allows the students to have an easier start, also making it clear what needs to be implemented.

On the other hand, it has drawbacks:

• We are forced to create a dummy data definition, which makes the exercise a little less challenging.
• We cannot export the data constructors to the test suite, because they do not exist yet.

Considering that most of the students don't go too far in the track, I'm not too worried about the risk of making it too easy, so I think it is worthy to try this path.

Related to #421.

[petertseng]

We are forced to create a dummy data definition, which makes the exercise a little less challenging

I don't think this is too serious. The student still has to figure out what they want the type to be, because they certainly won't be keeping the Dummy. So the only work we have relieved them of is the step of figuring out that we need to define the CustomSet type.

We cannot export the data constructors to the test suite, because they do not exist yet.

For this type CustomSet, a library writer might not want to export the data constructors anyway since it might show internal implementation details. So not being able to export constructors seems OK to me.

Regarding what a library writer might do, I think they would probably at least export CustomSet if not its constructors, otherwise nobody can refer to the type in a signature, etc. But it works for us since our tests don't refer to the type. I only make this comment because it's removed from the export list of the stub solution.

Overall, I feel the disadvantages pointed out are acceptable. The text in HINTS.md seems good. If you can't think of any other drawbacks I think we can get this moving.