The `TableBuilderHelper` now requires you to specify a `link_to`
attribute in a column you want to make a link out of instead of doing it
automagically as before.

Update the tests to do this and continue to output the right `<a>`s for
links.

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).

Rename this to `referential` to be more generic. This is because we
could be passing both `Referential`s and `LineReferential`s into this
parameter.

In `CompaniesController`, we use a `LineReferential` while in
`ReferentialCompaniesController` we use `Referential`.

Refs #3479

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.