Extract controller inheritance hierarchy from Thingybase

[bradgessler]

Extract the REST patterns from https://www.thingybase.com/ into a Rails lib to make the creation of other REST applications easier.

Here's what the controllers look like in Thingybase:

class MembersController < ResourcesController
  include AccountLayout

  protected
    def navigation_key
      "People"
    end

  private
    def self.resource
      Member
    end

    def resource_scope
      policy_scope.joins(:user)
    end

    def permitted_params
      [:user_id, :account_id]
    end

    def assign_attributes
      self.resource.account = @account
    end

    def destroy_redirect_url
      account_people_url @account
    end
end

Instead of using a DSL, Thingybase accomplishes laconic resource controllers via PORO. I have a few main controllers:

1. ResourcesController - What you'd expect: a controller for handling CRUD operations in a plural resource. Also handle auth, attribute allow-lists, etc.

2. ResourceController - Same as above, but for a singular resource.

3. NestedResourceController - This is where things start to get interesting. These controllers generally only have a new and create action that creates the resource within the scope of the parent controller, then it redirect to a ResourcesController so that the developer doesn't end up in a situation where they nest a bunch of resource controllers. An example of this would be a TODO list: the parent resource would be a List and the child an Item.

4. NestedWeakResourceController - This is the weird one; a "weak" resource is on where the parent resource is actually the same as the "nested" resource, but might not need the backing of a full ActiveRecord (or model). For example, the parent resource might be a Subscription. In a simple world, canceling a subscription would just be a delete action on the SubscriptionCancelation controller, but realistically you might have a CancelationController with a Subscription parent resource. The cancelation would make the flow a little nicer because you could show a new view for the cancelation that tells the user a few things about what they might need to do to complete the cancelation. To "confirm" the cancelation they would click on a button that creates a POST request to cancelations, which would then delete the subscription (or modify it).

[bradgessler]

The plan for 0.1.0 is to extract this from https://www.thingybase.com/ and re-integrate it into https://www.legiblenews.com/ and another project.

[bradgessler]

I need to figure out how to generate the equivalent of a ResourceApplicationController that lets people easily modify the behavior of 4 controllers: ResourcesController, ResourceController, NestedResourceController, and NestedWeakResourceController.

I'm not sure I'm thinking of this abstraction properly, but the fact remains that I need to generate some sort of ApplicationBlah file that people can modify with their own behavior that's inherited by all generated Oxidizer controllers.