Requested Improvements for developer experience with Freedom UI pages

Freedom UI pages do make many things easier/better for the no-code experience, but the developer experience has suffered as a result in some aspects, at least as it exists in 8.0.6. The following are items that are needed to improve the dev experience when working with Freedom UI pages:

1. Naming attributes for data source columns as column name (Must have)
   
   This one is critical. Currently, when you add a column to the page, it adds an attribute for the column in the viewModelConfig, however, it adds it as something like "FieldAttribute_yxzhag" instead of the field name, such as "UsrTheField". This means, if you're going to read or set values in that field from page handlers, you have to check what the attribute name is and use request.$context.FieldAttribute_yxzhag = "Some value", rather than using the actual field name as request.$context.UsrTheField = "Some value". This makes writing code for a Freedom UI page extremely difficult (or at least a huge pain). I do understand how the attribute names need to be unique and there could be attributes from the page and list data sources with the same name, but we desperately need a better way. My proposal would be to have primary data source attributes named as the field names (the editor could check if the same field is added twice to the same page and reuse the existing attribute). Any attributes added for non-primary data sources could get prefixed with the data source name (and would be fantastic to have consistent data source names as well. The primary always being named PDS and any list/lookup data sources named something like "ObjectNameDS"). Or at minimum, a built in set/get function that would lookup & translate the attribute name based on a provided data source path.
2. Objects created in page editor must allow for naming the object code (Must have)
   
   Currently, if you use the page editor and create a new object you cannot change the object code to give it a proper name and instead the object is named something like "UsrObject_xhsggy". This is a critical thing and honestly a deal breaker. This has to change to allow for naming objects. It's a lot of extra steps to create the objects separately in the configuration and then use in the page editor.
3. Methods on page to organize code (Nice to have)
   
   There needs to be some way to organize code outside of handlers. For example a methods node where methods can be added. If you were going to be handling 20 change events for things on a page, as it is now, you would have 20 if blocks all in the "crt.HandleViewModelAttributeChangeRequest" or you would need to have 20 separate "crt.HandleViewModelAttributeChangeRequest" handlers in order to organize or separate the code. Neither one is ideal and leads to the page code becoming a big mess. I started trying adding a methods node, with methods inside, to viewModelConfig, which worked great - however, that breaks the visual page editor. As it is now, I put page logic in modules that is called from the request handlers, but that seems like a lot of unnecessary work for code that is only needed for a given page. I get that this opens a big topic of whether the functions would need to be inheritable, which is what the request handlers are supposed to replace, however, I would settle for those functions only being considered a way to organize code, as an extension of sorts for the handler implementations (and not inheritable)
4. Built-in reference for devkit on pages (Nice to have)
   
   Since it's common to need to use devkit, rather than needing to add "@creatio-devkit/common" to the AMD modules on every page, it would be nice to have a built in reference on the page, available via something like request.sdk or request.$context.sdk etc
5. Adding esversion jshint to Freedom UI pages (Nice to have)
   
   For Freedom UI pages, the ability for the correct esversion for jshint warnings is needed. Currently, if you add a comment to the page schema /* jshint esversion: 11 */ this is removed any time you open the page in the editor
6. Inheriting/extending anglular UI components (Assumption/question)
   
   Since everything is componentized in the angular Freedom UI pages, I assume, hopefully correctly, that there is, or will be, some way to override angular components to extend the application beyond the editor and page view model. Extending things like crt.ContactCompactProfile, crt.AccountCompactProfile, crt.ActionDashboard, crt.AppToolbar, etc.
7. Would be nice to add to the rendered markup information about the components (Nice to have)
   
   In non-Freedom UI pages, it is extremely useful to be able to look at the rendered HTML of a page and you can tell what the component on the page is called, what the name of it's container is etc. For example in classic Creatio, inspect the top-right corner and you'll find out that the schema name there is MainHeaderSchema. This makes locating things and knowing what to look for very easy. All of this is lost with the angular components since those names are not a part of the rendered markup. It would be very nice/useful if that information could be somehow included in the resulting markup.
8. Using additional/other icons (Nice to have)
   
   It would be great if we could specify different mat-icon icons rather than using only the list of icons provided. The icon names don't appear to translate exactly to mat-icon names, it would make things much easier if it did so we could just change the name to a different one in the viewModelDiff.

Thank you. Also, kudos for so much amazing work on the new page editor and reducing the things needed as a dev task that can now be accomplished as a no code task!

Ryan