This reverts commit 28db706443a912e8355e4c48488dc40c403e7f76.

Turns out we didn't need to be able to pass an arbitrary number of
arguments to the lambda after all. The URL helper objects necessary in
addition to the first argument to the lambda can be retrieved from the
view context directly instead of passing them into the block as
parameters (which would actually make things more difficult, because the
block is called in the `TableBuilderHelper`, thus outside the scope of
the view).

This enables us to pass multiple objects into the lambda, so that we can
for example build a URL using a Rails helper using multiple objects.

Example:

    column.link_to(referential, item)

    lambda do |referential, item|
      some_path(referential, item)
    end

This tells the markup assembler whether or not this column should be
wrapped in a link (`<a>`). It intends to serve the same purpose as
`TableBuilderHelper#column_is_linkable`, but at the column level. The
idea is to remove that method when these links only operate by column
and not by pre-defined values like before/now.

This parameter will be used as the `href` to link the column value
somewhere.

We give it a lambda because this makes it easier to call any method on
the row object.

This means the accessor needs to take the object as an argument, like in
the `#value` method, because we don't have a better way to handle that
(it can't be done at initialisation time because at that point we don't
have row objects, we have a collection).

Instead of getting the referential to use when building the polymorphic
URL from the `UserContext`, pass in a referential directly.

The old code that used `user_context.context[:referential]` relied on
the fact that `ApplicationController#pundit_user` was defined as
follows:

     def pundit_user
       UserContext.new(current_user, referential: self.try(:current_referential))
     end

(We pass `pundit_user` into `CustomLinks` from
`TableBuilderHelper#build_links`.)

However, Robert's change 747d333ffbcc8ee0c9f1daf93ccca32799434e04
removes the `current_referential` call from `#pundit_user`. In
`CustomLinks`, we actually always want to be using
`current_referential`.

For example, on `Companies#index` (/line_referentials/:id/companies),
`CustomLinks` fails to build a correct #show link because
`user_context.context[:referential]` is `nil`, when it should instead be
a `LineReferential` object, that gets returned by the
`#current_referential` helper method. Sure, `#current_referential` is
hard to understand, so maybe we'll change that around in the future, but
this at least allows us to use the current referential in `CustomLinks`.

Refs #3479

The name of this method changed, but wasn't updated in the `describe`
label.

   -  All permissions tied to `!archived?`
   -  Tests adapted
   -  Policies refactored

   ?  Is `create?` permission bound to `organisation_match?`

We need the ability to say that an entire table is not sortable. By
default, all tables are sortable, and individual columns can have
sorting deactivated. This blanket deactivates sorting for all columns.

Take our `sortable` argument and pass it to `#thead`. Then
`#build_column_header` takes that value into account when creating a
header column value.

The actual label used in the column header is determined by the old
`#column_header_label` method. We've now moved it into the
`TableBuilderHelper::Column` class because it makes more sense there.
The method will now return the column's `:name` property if it was
defined, and otherwise gets the translation for `:key` as before.

Add a test on `TableBuilderHelper` that verifies that a table with
`sortable: false` returns the correct HTML without sorting links.

Refs #3479