Add notion of sampler

[luisfpereira]

Inspired by #9, this PR brings in the notion of sampler.

Notice this commit was initially done in 415cd8d.
Nevertheless, I believe this code is mature enough to merge (maybe after adding a notebook showing how this work?), whereas we still have a lot of work to do with #9.

Still need to address a couple of comments I've left in the code.

[gviga]

Hi @luisfpereira,
I was looking at and testing your implementation and I have some comments.

1. The major issue that I have is our choice to separate the notion of a Sampler and the NearestNeighbour Finder. I think we already discussed and if I remember correctly this is about the idea of a Continuous Sampler. However, I think that we need first to assume that a sampler is Discrete, and in this case, it is useful to have both vertices and indices as output, while separating the two can be expensive since a lot of methods naturally return both. I think a discussion on this needs to be made and maybe we will have a clearer idea after the implementation of other Samplers.

2. Particularly to this issues, i have wrote a notebook to explain the sampling and it is clear that with the code as it is now, we cannot have access to both vertices and indices without explicitly recover them.

Besides that, it seems that everything is working,

[luisfpereira]

Thank you for the comments and notebook @gviga.

1. The major issue that I have is our choice to separate the notion of a Sampler and the NearestNeighbour Finder. I think we already discussed and if I remember correctly this is about the idea of a Continuous Sampler. However, I think that we need first to assume that a sampler is Discrete, and in this case, it is useful to have both vertices and indices as output, while separating the two can be expensive since a lot of methods naturally return both. I think a discussion on this needs to be made and maybe we will have a clearer idea after the implementation of other Samplers.

Yes, the distinction is between continuous vs discrete.

So, I'm considering that doing mesh.vertices[indices] has a negligible cost (NB: maybe this is where we disagree; we may need to measure this). With this assumption, what would be the advantage of returning both indices and vertices?

My main goal is to have a compatible API for the DiscreteSampler and ContinuousSampler (think of those as abstract classes that we haven't added yet).
When we do .sample, both should return the point representation of a point belonging to a shape, i.e. i) if we are looking to a shape as a discrete object it will return indices (of vertices or faces, depending on the discrete object we're considering), ii) if we are looking to a shape as a continuous object, then it will return an array of vertices.

2. Particularly to this issues, i have wrote a notebook to explain the sampling and it is clear that with the code as it is now, we cannot have access to both vertices and indices without explicitly recover them.

What would be a use case of this feature in the notebook?

[gviga]

Yes, you are right,
now I understand.
We can say that each Continuos Sampler induces a Discrete sampler performing NNsearch in the discrete surface. In this sense, the NearestNeighbourIndexSamplerFunction would be defined only for continuous samplers. Maybe from this idea, we can find its new name.

I agree that calling vertices[indices] is not expensive and it's the way to go for now.

Thank you @luisfpereira