Fix how the API filters attribute and view names.

Attribute and view names are a bit of a special case in the API and are displayed as string representations instead of as a link to the attribute or view record that the record with the attribute or view is associated with. For example, in the Domain view, it has a `views` field which usually contains `["private","public"]` instead of something like `[http://127.0.0.1:8000/api/v1/dns/view/1/, http://127.0.0.1:8000/api/v1/dns/view/2/]`, since it seems pretty unlikely that the user will ever need to look up a view record directly. Likewise, with attributes, instead of having the `attribute` field represented as a URL like `http://127.0.0.1:8000/api/v1/attribute/1/`, it instead appears as `"Hardware type"` (or whatever), because that seems a lot more user-friendly. However, this leads to an annoying problem, which is that if you try something like `http://127.0.0.1:8000/api/v1/core/system/attributes/?i:attribute=Hardware+type`, you'll get an error, because internally `attribute` is not a string but a foreign key pointing to the record for the attribute "Hardware type". This PR solves that problem by automatically appending `__name` whenever the user attempts to do an inclusive or exclusive filter ending in the string `attribute` or `views`. The fix is a bit ugly, but I'm assuming we'll never have a record with a field name "attribute" or "views" that serves a fix other than the ones being handled here. If that does happen, I have an idea for a way to make some alterations to how filtering and SlugRelatedFields are handled, but for now this works.