Allow detection of entrypoint where shard.yml is not at workspace root

[mloughran]

In a monorepo setup, the shard.yml may not be at the workspace root, which means that currently crystalline cannot detect the entrypoint. For example:

• In my specific case, all crystal code exists within the imaginatively named /crystal directory. This contains a shard.yml which defines multiple targets. I deal with the multiple targets by creating a .crystalline_main.cr which requires all code, as suggested in the readme.

• One could imagine a different setup where a monorepo contained multiple independent crystal codebases, each with their own shard.yml (and in this case the code might not compatible and require-able at the same time).

Is there a way to handle these scenarios in crystalline?

From what I can tell the key starting point is Crystalline::Workspace#compile in https://github.com/elbywan/crystalline/blob/master/src/crystalline/workspace.cr, which has a file_uri? – I assume this is the current editor file? In this case the implementation of Crystalline::Workspace#entry_point could be changed to take the current file, which should allow implementing some reasonable algorithm for detecting the correct entrypoint.

A few options come to mind:

1. Add support for an optional .crystalline file, which points to the main shard.yml. This would work for the first setup, but wouldn't handle the second.

2. Walk up the directory hierarchy from the current file, stopping at the first shard.yaml which is discovered. I'd worry that this would cause issues when inside some shard for example.

3. Allow an optional .crystalline file to define an array of potential crystal root directories, and then pick one of these to use based on the current editor file.

Do any of the above make sense, or have I missed an existing solution to this problem?