Remove batch splitting system

[robknight]

This PR removes the batch splitting system, as it is no longer necessary with the new larger batches.

It also tidies up some of the lang crate APIs, simplifying them for common use-cases:

pub fn load_module(
      source: &str,
      name: &str,
      params: &Params,
      available_modules: &HashMap<String, Arc<Module>>,
  ) -> Result<Module, LangError>

Loads a module from Podlang source. Module files contain predicate definitions and imports, but no REQUEST block.

pub fn parse_request(
      source: &str,
      params: &Params,
      available_modules: &HashMap<String, Arc<Module>>,
  ) -> Result<PodRequest, LangError>

Parses a request from Podlang source. Requests contain a REQUEST block and imports, but no predicate definitions.

Having two dedicated functions for the different use-cases seems much cleaner than parsing a string and then inspecting the result to see if it contains a request or a batch (or both).

The import syntax has also changed: use batch is replaced by use module:

use my_module

test_pred(a) = AND(
  my_module::foo(a)
)

I'm very open to changing how this works, and this definitely ought to be discussed before merging.

---

The "apply_predicate" code now belongs to the Module type. However, we may want to move this to be part of the builder, in a later PR.

[ed255]

The removal of batch splitting looks good to me!
Regarding the new module syntax I would like to share some thoughts:

• Previously in a batch import we had to enumerate the list of predicates. Now we don't. I like this, because modules will easily contain tens of predicates.
• Accessing module predicates by namespace with `module::predicate syntax. I also like this.
• Not specifying the module hash in the code. I think I would prefer if the module hash appeared in the code because the module name is not universal (it's not used for cryptographic verification).
  • Now we have the use intro that uses a hash and use module that doesn't. I find this inconsistent
  • If we don't specify the module hash in podlang, we need to specify it somewhere else; but right now this somewhere else is a HashMap.
  • I think it would be nice to include the module hash in podlang code so that the podlang code pins the dependency of the module and removes any ambiguity.
  • I don't know what the syntax for this could be. Something like use module 0x123 as foo?

[robknight]

The removal of batch splitting looks good to me! Regarding the new module syntax I would like to share some thoughts:

• Previously in a batch import we had to enumerate the list of predicates. Now we don't. I like this, because modules will easily contain tens of predicates.

• Accessing module predicates by namespace with `module::predicate syntax. I also like this.

• Not specifying the module hash in the code. I think I would prefer if the module hash appeared in the code because the module name is not universal (it's not used for cryptographic verification).

  • Now we have the use intro that uses a hash and use module that doesn't. I find this inconsistent
  • If we don't specify the module hash in podlang, we need to specify it somewhere else; but right now this somewhere else is a HashMap.
  • I think it would be nice to include the module hash in podlang code so that the podlang code pins the dependency of the module and removes any ambiguity.
  • I don't know what the syntax for this could be. Something like use module 0x123 as foo?

Ok, I think we can use the module hash instead of the name, with the name being a local alias.

[ed255]

LGTM!