revisit use of "l-constrain" class vs built-in layout sizing

[jackmakesthings]

More a point for discussion than a definite action item at this time. WP now has an internal concept of widths and layouts that we could possibly be leaning on instead of using JS to add 'l-constrain' classes to a lot of content blocks - which often leads to doubled padding, narrow columns and other weirdness.

We can set up 'content' and 'wide' widths in the theme json/config yml. If we set the Post Content block in a template to 'use default layout', most blocks inside it will automatically get the same kind of max-width and side padding we've been adding with l-constrain. it'd be nice to use the native solution here. maybe we can do some kind of inventory of typical use cases and see if WP's solution covers our usual design needs.

[jackmakesthings]

I have now built maybe a half-dozen sites using root-padding and built-in constraints; I would be comfortable removing the .l-constrain file at this point, if folks agree.

[cssgirl]

I don't think we are using the l-constrain class anywhere within the default theme anymore. I also haven't been using those classes anymore using what we have by default in WordPress. I'm open to removing the file, but wondering if there are any arguments to keep it? Maybe we can just remove the gesso/source/02-layout/_constrain.scss file & reference and keep the mixin. We could add this as a part of https://github.com/forumone/gesso-wp/pull/444

[jackmakesthings]

I removed the files, we can close this one.